... 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@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@cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+ o