[saga-rg] Re: Fwd (s.newhouse at omii.ac.uk): Re: SAGA Strawman API

[Andre Merzky]

... and I also want to comment on some of them :-)
text inserted below.

Andre.


Quoting [Andre Merzky] (May 30 2005):
> 
> ----- Forwarded message from Steven Newhouse <s.newhouse at omii.ac.uk> -----
> 
>>> In order to advance the SAGA strawman API, we need urgently
>>> some feedback from outside the authors group.  
>> 
>> I have been carrying around for over month and have only just (late I'm 
>> afraid!) got round to looking at it. A few general comments...
>> 
>> 1. OO vs. functional
>> I can understand specifying in one language - no problem. But you need 
>> to show read across to different languages and systems.

The spec for now is supposed to be language independent - we
will define language bindings as soon as that spec
stabilizes.


>> 2. Task
>> Didn't understand this at all! Are you proposing to support 5 different 
>> systems or expecting one to be selected from these 5?

Oh - I wonder if we sent you an old version?  Its definitely
only one system - this one:

package SAGA version 0.1 {
  package TaskSubsystem {
    enum State {
      Pending   =  0,
      Running   =  1,
      Finished  =  2,
      Cancelled =  3
    };
    interface Task {
      run      ();
      wait     (in double timeout,
                out boolean finished);
      cancel   ();
      getState (out State    state);
    }
    class TaskContainer {
      addTask    (in Task           task);
      removeTask (in Task           task);
      wait       (in double         timeout,
                  out array<Task,1> finished);
      listTasks  (out array<Task,1> tasks);
    }
  }
}

Example:

  Directory dir;
  Job       job;
  
  DirectoryTaskFactory dtf = dir.createTaskFactory ();
  JobTaskFactory       jtf = job.createTaskFactory ();
  
  Task t1 = dtf.ls         (result);
  Task t2 = dtf.copy       (source,target);
  Task t3 = dtf.move       (source,target);
  Task t4 = jtf.checkpoint ();
  Task t5 = jtf.signal     (USR);

  t1.run ();
  t2.run ();
  ...

  TaskContainer tc;
  tc.addTask (t1);
  tc.addTask (t2);
  ...

  Array finished;
  tc.wait (timeout, finished);
  
  Array tasks;
  tc.listTasks  (tasks);
  tc.removeTask (t5);
  

>> 3. Security
>> Inconsistent use of security - it appears in the stream section but 
>> nowhere else. I think this is very wrong. Not specifying a security 
>> system makes sense, but I think all of thes emethods should have a 
>> security token being passed into them or it should be an argument in the 
>> relevant object constructor.

We have to flesh out a session handle like thing, which is
also to encapsulate security.  You are right - huge missing
piece...


>> 4. URL - P10
>> I assume the URL can support a number of protocols - 
>> http/https/file/gridftp. I see no way to register plugins in the 
>> interface (may be this is an 'internal' interface as opposed to a user 
>> funtion. Maybe there needs to be aet of interfaces to help the 
>> developers, e.g. register protocol plugins.

That is an implementation issue, really.  We could imagine
SAGA implementations which can only handle gsi and gridftp,
and other implementations which have a plugin mechanism and
can handle all types of protocols.

The latter is better we think, but the API spec does not
specify the implementation and architecture.


>> 6. Focus
>> The large number of APIs makes the document appear un-focuses. You 
>> mention a focus on tier 1 interfaces (which is good) but is this the 
>> whole document or a subset of the current draft? If its the whole 
>> document I think you need to drop more! Have this document as a 
>> framework but take forward a smaller document for standardisation. Samll 
>> is better!

Smaller is better for standardization, but also makes the
API less usefull, und less consistent over the various
parts.  We have been pondering quite a while over this.  

What would be your suggestion for a better document
structure?


>> 7. Partial Implementations
>> How are you going to handle partial functionality implementations? 
>> Should _all_ operations support a NotImplementedException ? Should there 
>> be a stndard static method in each section to discover what is 
>> implemented? e.g. supported protocols & supported methods.

Good one, we should document this: we think all
implenmentations hsould provide all methods (so no compile
problems), but can return an NotImplemented Exception.  That
is neccesary in particular if you have an plugin enabled
implementation...


>> 8. SAGA File Transfer.
>> You have an 'LSF' schema for >>, >, < & <<. But in the file/directory 
>> area you use a series of attribute flags. I think you should carry these 
>> attribute flags forward into the job definition area - either way I 
>> think you should have one model not two!

Right, we should check this.

>> General Thoughts
>> The document needs to be broken up IMHO - either into sections or 
>> individual documents.
>> I. General Model. Language mapping. Standard attribute model. Security. 
>> Tasks
>> II. Tier 1 Interfaces.
>> III Tier 2 and above Interfaces.

Ah, here is the proposed structure :-)

Language mappings go into specific documents anyway.  
To separate attributes, security and tasks seems a good
approach - they are common to all classes.

I am not sure if I understand your distinction between 
Tier 1 and Tier 2 - could you give an example please?


>> This would make it clearer what you are doing now & the constructs & 
>> concepts that you are using to build the model.
>> 
>> Hope that helps! Happy to clarify any of the above...
>> 
>> Regards,
>> 
>> Steven
-- 
+-----------------------------------------------------------------+
| Andre Merzky                      | phon: +31 - 20 - 598 - 7759 |
| Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 |
| Dept. of Computer Science         | mail: merzky at cs.vu.nl       |
| De Boelelaan 1083a                | www:  http://www.merzky.net |
| 1081 HV Amsterdam, Netherlands    |                             |
+-----------------------------------------------------------------+
o