[SAGA-RG] Fwd (andre at merzky.net): Re: JSDL - SAGA

['Andre Merzky']

Hi group(s), 

a couple of us had a recent discussion (f2f and email) about
JSDL and SAGA.  The question is: should we support JSDL
fully on API level?  E.g., should we allow the application
programmer to specify/use JSDL documents for job creation?

The reasons for doing that are compelling: JSDL is one of
the most acknowledged standards in OGF, and the number of
backends supporting JSDL is rapidly increasing it seems.
Supporting JSDL directly would allow to interface with other
tools using JSDL, and would allow to reuse JSDL documents
where these are already available.

Well, I have however some problems with that approach, which
are outlined in the cited email below.

Do you guys have any other thoughts, and what solution would
you prefer?

Cheers, Andre.


----- Forwarded message from 'Andre Merzky' <andre at merzky.net> -----

> From: 'Andre Merzky' <andre at merzky.net>
> To: Shantenu Jha <sjha at cct.lsu.edu>
> Cc: Hartmut Kaiser <hkaiser at cct.lsu.edu>,
> 	'Thilo Kielmann' <kielmann at cs.vu.nl>,
> 	'Andre Merzky' <andre at merzky.net>
> Subject: Re: JSDL - SAGA
> 
> Hartmut and I discussed that somewhat last week.  So he
> knows I am not wholehartedly for that option.  SAGA is
> supposed to abstract the low level details, not to expose
> them.
> 
> JSDL is going to define a number of extensions now.  Some of
> these extensions are very useful for us, others not.
> Mostly, they will be more complex than JSDL itself.
> 
> Are we going to support the extensions?  Which?  All/some?
> How to select?  What error do we report on unsupported
> extensions?  Do we mandate that extensions are supported by
> the backends?  Which?
> 
> Even w/o extensions: is the job description updated after an
> JSDL attrib is set?  What about those attribs which are not
> JSDL keys?  Assume an implementation which implements the
> existing SAGA job description keys: MUST it support complete
> JSDL now?  What error whould it report?
> 
> These are probably all solvable problems, and I do agree
> that there are advantages, i.e. the re-use of existing JSDL
> documents.  Anyway, IMHO we should be careful, consider if
> we really have enough use cases etc.  Also, a free function
> jsdl_to_job_description may do the trick, w/o complicating
> the job package itself.
> 
> Cheers, Andre.
> 

Another point I'd like to raise is: if HPC profile bekomes a
widely accepted OGF standard, do we support it directly,
too?  Or OGSA-Workflow?  Where to stop, and where is the 'S'
in that approach?

Andre.


> Quoting [Shantenu Jha]
>> 
>> What little I know, I think so to.
>> 
>>
>> Quoting [Hartmut Kaiser]
>>>
>>> Agree 100%
>>> The easiest way is probably just to add a attribute in the job description
>>> taking the whole JSDL.
>>>
>>
>> Quoting [Thilo Kielmann]
>>>
>>> Yes!
>>>
>>> 
>>> Quoting [Shantenu Jha]
>>>>
>>>> Shouldn't we ensure that SAGA consumes JSDL w/o any
>>>> problem/changes?
>>>>
-- 
"So much time, so little to do..."  -- Garfield