[dmis-bof] Comments on the charter?

[Michel Drescher]

Hi *,

On 12 Dec 2005, at 16:14, William E. Allcock wrote:

> FYI, I have requested a single 90 minute session for us.  The plan  
> would be
> to review and accept the charter, review some of the existing  
> interfaces,
> and begin a discussion of how they do or do not meet our charter /  
> community
> needs.

Good - let's hope we'll get a slot. If possible, can you try to avoid  
a clash with JSDL, ByteIO and NOMCOM?
(And possibly a million of other sessions as well ;-) )

> [...]

> Comments on your slides.  The first two use cases are standard put  
> and get.

Yes. I just wanted to use terms that are as neutral as possible.

> The third party transfer option is common, but raises some issues.   
> For
> instance, your use cases imply some things:
>
>  - you can contact the source or the destination
>  - you contact only one of them.

If I remember right, I gave examples for a source driven data  
transfer (3rd party push/put), and a destination driven data transfer  
(3rd party pull/get). Both use cases must be supported, IMHO. So,  
depending on the context (i.e. restrictions of a computing site), a  
client MUST be able to initiate the data transfer from either the  
source or destination side.

I can even think of a scenario where *both* source and destination  
must be contacted because the transfer request receiving party (in a  
GET situation this is the source, in a put situation the destination)  
requires the client to vouch for the requested data transfer.

>
> Are those requirements?  What if there is system that is always  
> driven by
> the source or the destination?  I.e., it specifies you must contact  
> one or
> the other?  What if there is system that wants the client to do the
> coordination and it contacts both ends (which is what standard FTP  
> does) and
> a broker trying to do some sort of co-scheduling might do?  What about
> standard HTTP which does not support 3rd party transfers?
>
> I would also argue that your final use case is actual just a get  
> followed by
> a put.

Yes, this is one possible implementation - UNICORE will have to  
provide a different implementation as the UNICORE Gateway is a  
required intermediate. So it will indeed act as a gateway in the  
literal sense. That is, it won't most likely stream the requests  
instead of a staged approach.

Cheers,
Michel