Changes to VOSpace 2.0

[Matthew Graham]

Hi,

Firstly the usual apologies if you get multiple copies of this message. 

VOSpace 2.0 was discussed at the recent Interop and a number of minor changes were agreed upon and I just wanted to raise these so that there are no contentions. 

(1) As discussed previously on this list, UWS jobs (transfers and search) will be initiated by sending the <Transfer> or <Search> representation to the appropriate endpoint.


(2) VOSpace identifiers will be amended so that '~' is an alternate character for '!':
"vos://nvo.caltech!vospace/mjg/table1" is equivalent to "vos://nvo.caltech~vospace/mjg/table1" and handled in the same way to get the IVORN of the VOSpace service (ivo://nvo.caltech/vospace).


(3) The following will be listed as core properties:

ivo://ivoa.net/vospace/core#groupread  = "group URI"
ivo://ivoa.net/vospace/core#groupwrite = "group URI"
ivo://ivoa.net/vospace/core#publicread = "true | false"
ivo://ivoa.net/vospace/core#quota
ivo://ivoa.net/vospace/core#length


(4) Access to a data object for multiple groups is handled by multiple group-read properties:

ivo://ivoa.net/vospace/core#group-read  = "http://some.group#1"
ivo://ivoa.net/vospace/core#group-read  = "http://some.group#2"


(5) The following operations are mandatory for a VOSpace:

getProtocols, getViews, getProperties, getNode, setNode, createNode, moveNode, copyNode, deleteNode, pullFromVoSpace

The following operations are optional:

pushToVoSpace, pullFromVoSpace, pushFromVoSpace, findNodes

The conformance matrix will be updated to show what goes with what. 


(6) A short cut way to put data into a VOSpace. The use case is that CADC have reported that it takes a long time to put a small file into VOSpace because of the minimum of 4 HTTPS connections that are required (not counting the data transfer connection itself):

1. POST Transfer job
2. POST to start job
3. At least 1 poll (GET) to see if the transfer has completed
4. GET ResultList

One of the issues is that the default entropy pool used by the JVM to make the HTTPS connections quickly gets used up and though it is possible to specify a stronger entropy pool to the JVM, this is an implementation specific detail that we do not want to have to enforce on all VOSpaces. 

The UWS spec does describe a way of implementing a synchronous service on top of UWS so we could adopt/adapt this for a quicker way to specifically support putting data in VOSpace with HTTP PUT:

1. POST Transfer job to /sync endpoint 
2. Service creates a job in the standard UWS system with the given parameters and sets the PHASE to RUN. The /sync endpoint then responds with a status 303 response to the URL /sync/{job-id} where the transfer endpoint is specified in the Job description (a HTTP PUT endpoint)
3. The client can then transfer their data to the PUT endpoint
3. The /sync/{job-id} endpoint blocks until it detects that the underlying job has finished at which point it responds with a status 303 response to the /{jobs}/{job-id}/results/status which gives details of whether the transfer succeeded or not.


Comments, thoughts, etc.

	Cheers,

	Matthew