Changes to VOSpace 2.0

[Matthew Graham]

Hi, 

On Jan 5, 2011, at 3:41 PM, Patrick Dowler wrote:

> On 2011-01-05 15:03:06 you wrote:
>> The user submits an HTTP(S) request to /sync which consists of a <transfer>
>> document detailing a pushTo/pullFrom transfer. The service responds with a
>> Redirect-GET which returns the Job document for the transfer to the user
>> with details of the transfer, i.e., endpoints.  At this point, the status
>> of the Job should be ERROR (if something went wrong) or EXECUTING (since
>> the endpoints are live and ready for data transfer). The Job status should
>> only go to COMPLETED when the data transfer has finished - the service
>> will need to monitor the data streams (or delegate the monitoring) to
>> determine when this occurs and respond accordingly.
> 
> Oh, I see. It is me that misunderstood the job state. I thought the job was 
> complete once the negotiation was done, but this is more sophisticated. After 
> the user PUTs the file (for example) the job will then be marked COMPLETED or 
> ERROR depending on whether that succeeds. Got it!

OK, I'm happy with this solution as well.

> That sounds fine, albeit harder to update the final job state if the protocol is 
> something outside your software (e.g. using some custom protocol directly to 
> irods, srb, etc). One will need some sort of event notification to hook into...

Yes, but this problem exists with VOSpace 1.x as well!

> It turns out we have just the thing in our implementation (the web service for 
> data transfers is separate and more generic than our vospace, but it already 
> has to call back to update some metadata like size, md5, etc so we can hook it 
> in there). I guess maybe some of the metadata requirements make that messaging 
> necessary in general...

	Cheers,

	Matthew