[SAGA-RG] python bindings

[Sylvain Reynaud]

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 at 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
>