Grid SuperScalar:
-----------------

The SAGA API version 0.2 is useful for our requirements but we find some things
missing. We detail more each part of the API:


 - Session and Context: 
   
   We don't have any special requirements in this area.
 
 
 - Error: 
 
   No information given in the specification.
   
 
 - Task: 
 
   As it is supposed to be the asyncronous version of each SAGA API method, we
   think that this may be also useful for us in order to do asyncronous job
   submission, like the one achieved with
 
     globus_gram_client_register_job_request 
 
   in contrast with
 
     globus_gram_client_job_request.
 
 
 - Attributes and  Name spaces: 
 
   No special comments.
 
 
 - Files and Logical Files: 
 
   This two interfaces are very good if you want to access to a remote file in
   the first case, and to work with a replica location system in the second
   case, but nothing is provided in order to copy files from one machine to
   another if you don't want to use a replica system.  In our use case, our
   run-time is aware of the location of files, so an easy mechanism in order to
   copy files between machines must be provided. This is not easy to do as the
   API is now. A possible solution is to include copy, move or erase methods for
   files in the File API.
 
   <<<
     Comment Andre:
     --------------

     I think there is a misunderstanding.  The file packages is inheriting 
     from the NameSpace package.  That is, a saga::file implements the
     saga::name_space_entry interface, and a saga::directory implements the
     saga::name_space_directory interface.
   
     All operations which are agnostic to content of the file (such as create,
     copy, move, open, rename, list, ...) are defined in the namespace
     interface.  That interface is also inherited by the logical_file package,
     so the same methods are available there.
   
     Hence, the logical_file and the file packages only have those methods
     defined, which distinguish them from simple name spaces.
   >>>
 
 
 - Jobs: 
 
   It covers our needs in order to describe a job (also in terms of adding
   restrictions to a job) and we think the job state diagram is complete. The
   only thing we find is missing is a call for waiting till a notification
   arrives (whatever the notification is). We submit several jobs at the same
   time, and we need to receive notifications of the states of those jobs in
   order to take actions in our run-time. So we follow a notification model
   instead of a polling model (we wait for notifications for arrive, instead of
   polling for state changes from our run-time). In our opinion the API would be
   more complete if it includes both models for job state control (polling and
   notification model), so this gives more freedom to the API user.
 
 
 - Streams: 
 
   This API also is useful for us, in order to achieve communication between the
   workers and the master in an easy way to exchange a reduced amount of
   information.