On 27.11.2006, at 15:51, Dave Morris wrote:
>
>> * I was not keen on the "control" objects polluting the namespace
>> in the sense that as illustrated in the document that they would
>> appear directly in listings
>
> Yep, I agree.
> Sorry, I haven't updated the document since we talked.
> The status nodes should not appear alongside the data nodes.
>
>> - I would much prefer that any such control objects attached to a
>> data node were only accessible by using the ? (query) portion of
>> the vos url - e.g. the full URL to obtain the transfer status for
>> a data node could be
>>
>> vos://org.test!vospace/container/node?transfer
>>
>> and a list of all pending transfers for the space itself could be
>> referred to by such a query on the root node.
>
> Not sure about that one.
> There are possibly better uses of the ? operator - and we can only
> use it once.
>
> The functionality you describe could be handled by a separate
> ListStatusNodes() method.
> You pass in the URI of the data node you are interested in, and it
> returns a list of the active transfers for that node.
> We could extend it later to query for all the active|completed|
> failed|canceled transfers over a specific time range ... giving us
> a history of the target data node.
I guess that I am arguing for what we could do if there was no ListStatusNodes() method and this was done with the existing API - we could use this part of the URL for multiple things - I was not really very careful with the syntax but if we had something like
vos://org.test!vospace/container/node?operation=transfer_status
we could then do things like
vos://org.test!vospace/container/node?
operation=get_view&view=jpeg_cutout
which leads me to the thought that perhaps we are being too purist not having a direct getContent(URI) SOAP call that does return the "content" of the URI as a synchronous result, in-line. With the formal XML being a choice of an "any" xml or a small xml structure with a <data> element with base64 encoded data in it, so that either the actual node data could be returned, or any of the control objects (actually pretty much the same as Amazon S3 - getObject method). OK- this is not as efficient as the multiprotocol data transfer methods, but it does give the client something very simple that it can implement, and perhaps we can also say that servers are allowed to throw a "fetch with multiprotocol transfer method instead" exception if they feel that a data object is being requested is too large to return in-line.
Paul.
Paul Harrison
ESO Garching
www.eso.org
Received on 2006-11-27Z16:41:56