[SAGA-RG] python bindings
Sylvain Reynaud
Sylvain.Reynaud at in2p3.fr
Mon Sep 5 08:07:54 CDT 2011
Le 05/09/2011 12:27, Andre Merzky a écrit :
> On Sat, Sep 3, 2011 at 12:21 PM, M.A. Santcroos
> <m.a.santcroos at amc.uva.nl> wrote:
>> 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?
> Well, at least in C++ we do the same: 'normal' constructors for the synchronous
> operations, factory like create methods for the asynchronous ones. There are
> other ways to render that in an API, for example a two-step initialization,
> but that seemed to be easiest back then. I don't think the LSU SAGA bindings
> expose the async factory methods.
>
>
>>> 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?
> You cannot sensibly standardize the URL name space - that will get
> quickly out of sync with that 'reality' thing ;-) The same holds for
> security contexts, which at the end are also just pointers into some
> (backend defined) namespace.
>
>
>>> 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.
> Well, the URLs are pointers to endpoints. A GRAM endpoint,
> for example, will in general have a well defined https URL,
> which should be valid for all SAGA (and non-SAGA) implementations
> which want to use that endpoint (unless the implementation does
> strange things). The problem only arises where endpoint have no
> well defined URLs associated (fork:// versus local://).
The problems also arises with protocols which need additional
informations from WS-Adressing header or from attributes in the legacy
API, with protocols which use non-standard URL (for example with a
fragment separator before the path), and with protocols that use the
same scheme if the SAGA implementation wants to avoid late-binding (this
is the case for JSAGA), and probably many other examples that we have
not faced yet...
...but I think these examples are one more reason to leave some room for
interpretation of URLs in the spec !
> Similar for security contexts: the spec specifies a set of attributes
> which seem to map to most security tokens known to us - unless the
> SAGA implementation does strange things, you should always be able to
> use the 'UserProxy' attribute to point to an X509 certificate, etc.
I agree ; SAGA implementations can have lot of differences in the
attributes needed to generate the credentials (i.e. *-proxy-init for
example), but they should not have so much differences in the way to
simply use them.
But be careful, even if they are built with the same string value(s),
currently the URL/Session objects passed in the SAGA method arguments
must be created with the right SAGA implementation (maybe this last
point can be improved in the SAGA implementations ?).
Cheers,
Sylvain
> But SAGA cannot sensibly anticipate all possible security token
> attributes, as some of them are even deployment-dependent. That is
> why the security context attributes are extensible...
>
> Cheers, Andre.
>
>
>> Cheers,
>>
>> Mark
>>
>>
>
>
More information about the saga-rg
mailing list