VOSpace v1.15 PR comments

[Dave Morris]

Norman Gray wrote:

> Sect 3.5.4.2: "Local NFS transfers".

This example originally came from me, so I'd better explain why .

> This talks of transfers within a specific local NFS filesystem. This 
> is so local that it strikes me as odd that anyone would want to 
> register an IVORN to describe it -- why would anyone not on this local 
> system ever need to look this up?

Short answer, error handling, expert users and transparency.

Consider a set of VO services (VOSpace, TAP, UWS etc) installed at 
Cambridge all able to access the internal Cambridge NFS network.

A user from outside, perhaps yourself located in Glasgow, can initiate 
operations that result in data transfer between two of the services at 
Cambridge. Ideally, you want the services to use the most efficient 
protocol to transfer the data, but as an external user you don't know 
(and normally shouldn't need to know) the details of the internal NFS 
network at Cambridge. Which is as it should be, you just want the bytes 
transferred. However, because your user agent (program) was involved in 
the protocol negotiation, it does know the the identifiers for which 
protocols were offered and used.

Two reasons why the end user may want to know more.

First case is what happens if something goes wrong ?
Unless the error messages passed back to the client are very generic 
'something bad happened', they may contain details that are specific to 
the transfer protocol used.

If the error message says :
'[specific bad thing happened] during transfer using [protocol] '

The system still works if [protocol] is an opaque URI, but the message 
may be more informative if [protocol] points to a resource that 
describes what it is.

Second case is an expert user who has more detailed knowledge of the system.

In the real world, there will always be cases where domain experts know 
more (or think they know more) about the system.
In which case, there may be cases where the user wants to be able to say 
things like
'transfer data between [source] and [destination], using [protocol]'
or even
'transfer data between [source] and [destination], but don't use [protocol]'

Again, the system functions fine if [protocol] is an opaque URI, but it 
is more informative if it is resolvable to something that describes what 
[protocol] is.

All of the above works fine whatever the URI actually is.
If is an opaque URI, then the system functions, but the user can't find 
out more.
If [protocol] is a http URL that points to a web page, then the user can 
read the page, but a program can't.
If [protocol] is a URI that points to a resource with a known XML 
structure, then it may enable future programs to understand what 
[protocol] actually means.

The more public the URI, the more a use can find out, and the more 
control they have.

> Indeed, it strikes me that one could reasonably insist that a site 
> SHOULD NOT register such cluttering IVORNs.

Interesting.
This implies we want to have restrictions on what types of things can 
and can't be registered in the registry ?

For VOSpace, the system works just as well if [protocol] is a http URL 
which points to an XML resource, as long as the structure of the XML 
resource is well defined and can be understood by VO clients and users.

Using the VO registry (seemed to be) a convenient (VO compatible) way to 
get the process started. Most VO tools are able to resolve and display 
registry resources, removing the need to create a new XML schema and 
associated tools.

In practice, using registry resources is not ideal and it has imposed 
restrictions on what we can express in the resources. However, at the 
time we felt that if we started to define our own XML schema for things 
like this, there was a danger that we would end up with multiple 
incompatible and overlapping XML schema within the VO.

In hind sight it might have been better/easier for us to use http URLs 
and define our own XML schema for the protocol definitions, and we may 
want to consider this for VOSpace 2.x services.

Dave