Christopher Smith wrote:
On 10/11/05 10:35, "Frank Siebenlist" <franks@mcs.anl.gov> wrote:
Mark McKeown wrote:
Regarding Chris's desire to be able to pass the LSF jobid back to the client somehow - it could be included in the EPR's Metdata, possibly RDF could be used to mark up the Metadata to indicate that it is a LSF jobid. In this way the Address IRI can be kept opaque.
That would seem to me to be needless disambiguation. Surely it is just up to the service that mints the abstract name to understand it; there is no inherent need for it to explain what that means to anyone else.
I am not sure I understand your comment - you don't seem to be disagreeing with me...
Frank wants to use the EPR's wsa:Address IRI as an AbstractName, Chris wants to send a LSF jobid to the client and the W3C recommends that IRIs should be opaque. One way to include the LSF jobid in the EPR is to embed it into the wsa:Address IRI, this might help make it unique and the client could extract it from the IRI - however the W3C recommends that IRIs should be opaque.
Well, I also believe that it's better to keep the IRIs opaque and was suggesting to use the complete IRI itself as an alternative jobId.
Whether that could work depends on the use cases we have to consider...
See this is exactly what I want to avoid.
Our customers are used to seeing a regular jobID (now if this is generated by a higher level scheduler that understands checkpointing and migration and the fact that lower level jobids might change, that's fine). The use this jobID within command line tools and web portals to access information about their job. The web services interfaces are now an additional interface to these others. Why should I bring WS baggage along (in the form of EPRs and IRIs as identifiers) when I have one that our users understand already. I don't want to have to retool my CLI and other existing interfaces to now take some other structured identifier.
The abstract name seems to me like a nice way of providing this identifier in the context of the WS interface. Sure, many of the alternative proposals would do the trick as well, but I had always been under the assumption that clients weren't supposed to interpret the EPR elements.
I can relate to your CLI requirement, but as I've noted before, using an AbstractName will not solve your warm-body interface problem as all globally forever unique IDs are not user friendly. If I understand it well, then what you want is to work within the context of a CLI interaction such that you can use relatively small numbers for jobIDs that only have to be unique within that context. In other words, your job#12 today will be different from you job#12 tomorrow, which requires confinement to context. You could probably still use AbstractNames and use some naming convention to essentially concatenate a contextId and a small numbered jobId... and define your own URI-schema for that. Of course if only you were "allowed" to parse those EPR-Address URIs, you could do the same thing ;-) Regards, Frank. -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory