On 28.11.2006, at 06:30, Dave Morris wrote:
> Paul Harrison wrote:
>
>> 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
>
> We are designing a SOAP webservice - so why add yet another syntax
> for calling methods.
> If we didn't already have a SOAP service, then you might have a case.
because a major thing that people want to be able to do is use a URL to identify a dataset when publishing a paper for instance - if views are allowed that alter the presentation of data, then it is not really very pretty to have to write a chunk of xml that represents the call to VOSpace to be able to make the statement - "get this dataset with this particular view" as a reference in a paper. However, it is not a showstopper for 1.0 - but something to consider for the future. If we can find a good compromise between the advantages of SOAP with some REST-like semantics in the vos: URI, it would be appreciated by the users.
>
> How about this :
>
> <method uri="[dime-get-inline]"/>
>
> Where the URI points to a resource that says something like this :
>
> ivo://net.ivoa.vospace/transfer-methods/dime-get-inline-1.0
> This is a VOSpace transfer method that uses the Direct
> Internet Message Encapsulation (DIME) message format to return the
> node contents as a SOAP attachment.
> Details of the DIME specification can be found at here
> [http://msdn.microsoft.com/library/en-us/dnglobspec/html/draft-
> nielsen-dime-02.txt]
>
> Usage:
> The client calls PullFromVOSpace specifying this transfer-
> method in the request.
> If the request is valid, then the server will respond with
> the standard PullFromVOSpace,
> response, and attach the data node contents to the end of the
> message as a DIME attachment.
>
> The transfer completes when the SOAP response is received by
> the client.
> No additional steps are required.
>
> If the server is unable to attach the data node contents to
> the message, then it either
> will response with the appropriate error message, or a list
> of other transfer-methods
> if they are available.
>
> Or this :
>
> <method uri="[mtom-get-inline]"/>
>
> Where the URI points to a resource that says something like this :
>
> ivo://net.ivoa.vospace/transfer-methods/mtom-get-inline-1.0
> This is a VOSpace transfer method that uses the Message
> Transmission Optimization Mechanism (MTOM) message format to return
> the node contents as a SOAP attachment.
> Details of the MTOM specification can be found here [http://
> www.w3.org/TR/soap12-mtom/]
>
> Usage:
> The client calls PullFromVOSpace specifying this transfer-
> method in the request.
> If the request is valid, then the server will respond with
> the standard PullFromVOSpace,
> response, and attach the data node contents to the end of the
> message as a MTOM attachment.
>
> The transfer completes when the SOAP response is received by
> the client.
> No additional steps are required.
>
> If the server is unable to attach the data node contents to
> the message, then it either
> will response with the appropriate error message, or a list
> of other transfer-methods
> if they are available.
>
> Both of which are possible within the current VOSpace version 1.0
> specification.
These are fine, and having the attachment as part of the control method SOAP call is much my preferred way of doing things - Appendix A of the current draft of the standard is still a little confusing in this respect, as it makes it sound as if the expected way for attachments to work is by calling another service, which defeats the point of attachments a little in that the whole operation to get or put data is no-longer atomic nor synchronous.
just one more point - why do we need to distinguish between get and put?
>
>> .... (actually pretty much the same as Amazon S3 - getObject
>> method). OK- this is not as efficient as the multiprotocol data
>> transfer methods ....
>
> See : http://solutions.amazonwebservices.com/connect/ann.jspa?
> annID=144
> Posted : Oct 23, 2006 11:21 PM
> /In a few weeks time, you will no longer be able to use the Amazon
> S3 SOAP interface's PutObjectInline or GetObjectInline for objects
> that are larger than 1 megabyte in size. After November 21,
> affected requests will fail with the new error response
> InlineDataTooLargeError. To put or get objects that are larger than
> 1 megabyte in size, you will need to either use DIME attachments
> with SOAP requests or use our REST interface. We apologize for any
> inconvenience this change may cause you.
>
> Please be assured that deprecating existing functionality is not a
> change we take lightly. We are making this change because
> transferring large objects inline in the SOAP message (as happens
> with PutObjectInline and GetObjectInline) has significant negative
> performance implications; it is a mechanism only suited to
> transferring small amounts of data. The SOAP-based alternative,
> using DIME attachments, now has wide support in SOAP toolkits, is
> more efficient and does not suffer from the same performance
> bottlenecks. It also allows us to optimize our service to give you
> better performance./
ok - how amusing - I guess we can say "told you so" - they are still
leaving the method there for small transfers however...
>
>> .... but it does give the client something very simple that it
>> can implement ....
>
> What is so difficult in a client implementing this :
>
> <method uri="[http-get]"/>
>
> Where the URI points to a resource that says something like this :
>
> ivo://net.ivoa.vospace/transfer-methods/http-get
> This is a VOSpace transfer method that uses the standard http-
> get transport protocol.
> Details of the transport protocol are available here [http://
> www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3].
>
> Usage:
> The client calls PullFromVOSpace specifying this transfer-
> method in the request.
> If the request is valid, then the server will respond with
> the standard PullFromVOSpace,
> response, and add a <transfer-method> element containing the
> endpoint URL to fetch the data from.
>
> The client uses the URL to download the data using a standard
> http-get request.
> The transfer method completes automatically when the client
> has received the data,
> and no notification callbacks are required.
The real point here (and part of my motivation for suggesting the in- line data transfer), is that the bare VOSpace specification does not mandate any minimum data transport mechanism that a space has to implement, so there is no guarantee that two fully compliant 1.0 VOSpaces can actually exchange data, which I think is a shame.
Paul Harrison
ESO Garching
www.eso.org
Received on 2006-11-28Z11:22:35