Hi Steven, thanks for your comments, I forward them to the list - hope you don't mind. Cheers, Andre. ----- Forwarded message from Steven Newhouse <s.newhouse@omii.ac.uk> -----
Date: Sun, 29 May 2005 14:47:40 +0100 From: Steven Newhouse <s.newhouse@omii.ac.uk> To: Shantenu Jha <s.jha@ucl.ac.uk> CC: Tom Goodale <goodale@cct.lsu.edu>, Andre Merzky <andre@merzky.net> Subject: Re: SAGA Strawman API
Hi Shantenu,
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.
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?
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.
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.
5. Languages These examples (with the OO background) obviously look very Java. I think you need a section (but not for each area) showing how the interfaces get rendered in different areas. This will help adoption & buyin from Perl, Python, F77, C, & other communities. How are the exceptions handled in different programming languages? I'd almost be tempted to return all error codes from the function as the return value.
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!
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.
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!
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.
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 | | +-----------------------------------------------------------------+