copy/move/pushFrom/pullTo

Patrick Dowler patrick.dowler at nrc-cnrc.gc.ca
Tue Sep 20 13:18:34 PDT 2011


We are implementing the various transfers (beyond the client-initiated 
pushToVoSpace and pullFromVoSpace which we already have) and it isn't entirely 
clear to me. I'll just refer to copy below since the only difference is the 
value of keepBytes, but the ideas apply to move as well.

First to clarify the server-server copy (eg 5.4.4 pushFromVoSpace). Say we 
want to copy a file from server A to server B. We are going to get server A to 
do it, so it is pushFrom and the target gives the source vos URI in server A 
(to which the transfer is submitted). The transfer also includes protocol(s) 
with endpoint(s) to which the data is to be written. Is it assumed/required 
that the client gets those protocol/endpoint(s) itself?

eg. they could be some arbitrary http server and the example makes sense, or 
the destination could be a vospace, in which case the client negotiates a 
"pushToVOspace" with server B, extracts the protocol/endpoint(s) and then 
submits them in the transfer job to server A.  Then server A does the http PUT 
(for example) to server B.

Can the client simply specify the destination as a (vos) URI? eg let the 
server negotiate the protocols? If not, is there some scenario that justifies 
forcing the client to do this? (note: the client would have to get the list of 
protocols from serverB, construct the transfer with all of them, then send 
that to serverA and hope there was overlap... so clients would likely get the 
lists from both and check for overlap and then submit the transfer, which 
could in theory still fail to find a common usable protocol... so they still 
have to look in the transferDetails to see what was agreed upon)

On the other hand, by requiring a vopsace service to handle external vos URIs, 
you require them all to be clients too. Sort of a peer-to-peer style... that 
is an implementation burden, but not a large one since the client part should 
be common code written to the spec, not implementation-specific. Practically, 
one more or less implements a client in test code anyway :-)

While thinking about that, look at the the internal copyNode: one submits a 
transfer with a target (the vos URI of the source node) and a direction (the 
vos URI of the destination node). The two vos URIs are in the same service 
(same authority). Clearly one wants to express this with just URIs so the 
service can optimise this operation (and move).

If the two vos URIs had different authorities, the source and destination would 
be in different vospace services... presumably illegal in the current spec 
(InvalidURI fault?).

Thoughts? 

-- 

Patrick Dowler
Tel/Tél: (250) 363-0044
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2M7

Centre canadien de donnees astronomiques
Conseil national de recherches Canada
5071, chemin West Saanich
Victoria (C.-B.) V9E 2M7


More information about the vospace mailing list