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