[dmis-bof] Comments on the charter?

[Michel Drescher]

Hi all,

On 14 Dec 2005, at 17:06, Peter Kunszt wrote:

>>>>  - we need to address naming.  What will we accept as source and
>>>> destination names? URLs? URIs? any string? EPRs?
>>>
>>> URL seems like a good choice, this would probably suit all
>> use cases.
>>> this is what we use in the GSM-WG. we have storage URLs.
>>> an EPR is nothing more than a decorated URL so a simple URL
>> would suit
>>> that too.
>>
>> URLs work fine for files, and I *suspect* it will be what we
>> use for V1.0, but if we take our file blinders off and try
>> and think about source other than files, i.e. a service that
>> is virtualizing some non-file data source, we might want
>> EPRs.  This is related to the next issue.
>
> well, if you take rich URLs, you can get away with anything.
> ?query=...

I strongly support URLs. Note that, opposed to the very popular  
perception, URLs describe *resources*, not (only) files. Apart from  
the scheme and authority parts of URLS (i.e. "http" and  
"forge.gridforum.org[:80]") URLs describe resources in a  
hierarchically ordered domain. THe query part is just a piece of  
information that further transports information specific to the  
addressed resource.

So if you want to publish for example the coffee temperature in your  
mug using HTTP, you could do that with the following imaginary URL:

	http://users.mcs.anl.gov/~allock/resources/sensors/coffem-mug? 
refresh=10

Requesting that URL may result in a nice data stream sending the  
current temperature in 10 second intervals.
Note that the path element does not necessarily have to map to a file  
system path - refer i.e. to the J2EE Servlet specification that  
splits the path information into three elements:
- context path (a J2EE enterprise application)
- servlet path (a locator for servlets within a J2EE enterprise  
application)
- path info    (the residual URL path element)
All three elements concatenated form the original URL path element;  
and the context path and servlet path may be null. The mapping is  
purely virtual and is specified in the EAR deployment descriptors.

>> I guess now that I think about it, your way works too.  As
>> long as the query mechanism is there, as long as you don't
>> send a block the site doesn't support, you wont fail
>> validation... I don't like it, but unless we discover a
>> bigger problem than that, I guess it is an option :-).
>
> the trick is easy. you put in an element that you don't define.
> you then extend it and play around the way you like it, and once
> you know what you want, you just take it into your mainstream
> WSDL as a proper part of it. see our discussion/example in
> https://uimon.cern.ch/twiki/bin/view/SRMDev/XmlSolution

This URL requires authentication which I cannot provide for AFS...

>>
>>>
>>>>  - what about scheduling / planning aspects?  Do we want
>> to include
>>>> elements in this WSDL that specify rate (bandwidth),
>> quantity (file
>>>> size), and timing (START BY, FINISH BY, etc)
>>>
>>> our experience: individually for each transfer job: no.
>> that is very
>>> complicated and of questionable use.
>>> on the scale of the service itself as a service
>>> parameter/configuration: yes.
>>
>> I half agree with you.  Clearly the service, may want to have
>> limits that can be set.  In that regard, it is acting as a
>> resource manager and protecting the resource for which it is
>> responsible, much like a compute scheduler.  Btw, I would
>> argue that this is outside the scope of this working group,
>> since an external entity has no need to be involved with
>> that.  At most we might want to agree on some state that such
>> a service MAY (in the SPEC sense of the word) expose.
>>
>> However, it is not clear to me that requests per job are of
>> questionable use.  Clearly they should be optional elements,
>> but if the submission has no such information, on what basis
>> does the service make decisions when it has a resource
>> constraint?  I would also add priority to the list.  If I
>> have multiple jobs submitted, I may want to make sure that
>> one of them gets service over the others.
>
> ok, i was sloppy. it is true that you should be able to influence
> the priority of your transfers and maybe even their speed/bandwidth
> within your allocated 'quota'.

Yes, I agree here as well. We're on the right track I think, so let's  
fight over the details in the meetings. ;-)

Cheers,
Michel