JSDL 1.0 does not support conditionals. These were removed (in their last form - profiles) from the JSDL spec at GGF 13. It is a subject we wish to re-visit this post JSDL 1.0 release. steve.. Andrew Grimshaw wrote:
All, Is there a way to do condition statements in JSDL, in other words the implementation that is "executing" the JSDL can choose which of several options?
Andrew
-----Original Message----- From: owner-jsdl-wg@ggf.org [mailto:owner-jsdl-wg@ggf.org] On Behalf Of Steve McGough Sent: Thursday, June 09, 2005 7:07 AM Cc: JSDL WG Subject: Re: [jsdl-wg] Question on file stage-in (fwd)
I think at this point we should remember that JSDL 1.0 is a minimum specification. All consumers need to be able to deal with the elements we define.
I do agree with Andrew that optimised transfers are very useful and it's a prime example of an extension to JSDL that should be done. Then at some point in the future you'll have services which handle the useful extensions and some which don't. People will submit jobs to services which have the extensions they desire - though could use the others if they have to. This will hopefully cause services which don't have the extensions to upgrade or "mimic" the features so they do get jobs. This is something I've already seen signs of.
steve..
Donal K. Fellows wrote:
Andrew Grimshaw wrote:
In the data staging elements there is a creation flag that indicates whether to over-write or append.
Often, one only wants to overwrite if the target and the source are different, for example if I am using a large data set that changes infrequently or several jobs on the same resource will use the "same" input file. Is there a way to do conditional stage in?
My understanding is that the implementation is free to use some mechanism outside the JSDL scope to optimize downloads. From the JSDL perspective (not that this is the only valid perspective, of course) it doesn't matter all that much. Looking at the latest version of the spec though, I see that the value "jsdl:dontOverwrite" could be interpreted to mean "transfer only if not pre-existing". Of course, at that point you then have to worry about whether the two ends refer to the same data, but if you're piling the data into some job-specific dir that's IMO not a huge issue.
I know the document says
"More complex file transfers, for example, conditional transfers based on job termination status are out of scope. "
But we're talking about a major performance optimization.
Well, perhaps. But if we add it, we have to worry about systems that don't have a mechanism for doing this sort of thing in the first place. Indeed, the JSDL 1.0[*] spec leaves out many things that could be major performance wins (e.g. compressed data transfers) either because they're complicated in their own right, or because we decided to get a spec going *this* decade as opposed to the next one. :^) None of which means that we will not go back and revisit these issues once there is some more data and experience reports available on actual deployed implementations. In particular, as it is a spec put together by mainly compute guys, we know that the data-related part is in need of fleshing out in the future.
We've not reached the end of the story. Maybe just the end of the chapter instead. ;^)
Donal. [*] As a side note, it should be done just about now as I write this. :)
-- ------------------------------------------------------------------------ Dr A. Stephen McGough ------------------------------------------------------------------------ Research Associate, Imperial College London, Department of Computing, 180 Queen's Gate, London SW7 2BZ, UK tel: +44 (0)207-594-8310 fax: +44 (0)207-581-8024 ------------------------------------------------------------------------ Assistant Warden, Brabazon House, Pimlico, 5 Moreton Street, London SW1V 2PN, UK tel: +44 (0)207-828-4733 fax: +44 (0)207-233-8105 ------------------------------------------------------------------------