Hi Mark, I would call that a "limitation" rather than a "defeat". Indeed, creating URLs and security contexts is generally a small part of application code, so having a standard API is still useful for all the rest of the code! Yes there is some room for interpretation about URL and security contexts, but I am not sure if it is too much... For example, with URLs ; should the SAGA specification enumerate all the possible schemes for all existing technologies, and then be updated each time a new technology is born ? The same question applies to security contexts as well, because their attributes depends on which information is required by the middleware, rather than which functionnality we want to provide to users. I am not saying that we should not try to overcome this "limitation", but I am not sure that the SAGA-Core specification document would be the best place for this. Cheers, Sylvain Le 03/09/2011 12:21, M.A. Santcroos a écrit :
Hi Sylvain,
On 9/2/11 10:40 , "Sylvain Reynaud"<Sylvain.Reynaud@in2p3.fr> wrote:
Andre, I think you're right about the reason for the create() method ; it can indeed return a Task object that will contain the created object. I don't really understand that. So how does that differ from the LSU functionality?
Mark, FYI you can configure JSAGA's "local://" adaptor to be mapped to URL scheme "fork://"... but anyway, there are many other differences between URL of various SAGA implementations (independently of the implemented binding). The other main difference between SAGA implementations is between the security contexts. How come? Was there too much room for interpretation in the spec?
So if you want to develop an application that uses several SAGA implementations, creating URLs and security contexts will require implementation-specific code anyway. I don't consider that a feature obviously. It kind of defeats the purpose of having a standard API.
Cheers,
Mark