Changes to VOSpace 2.0
mjg at cacr.caltech.edu
Wed Jan 5 15:58:54 PST 2011
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...
More information about the vospace