VOStore interface

[Paul Harrison]

Matthew Graham wrote:
> Hi,
> 
> I think that most of what is VOStore and what is VOSpace is clear; 
> however, the two grey areas are access control (authorization) and 
> identifiers and this stems from the use case where the user wants direct 
> access to a VOStore (e.g. a local store) and does not want to go through 
> the VOSpace layer. 

This is is the core issue of the interaction between the layers - if 
VOSpace is supposed to be  effectively a catalogue of what is in 
VOStore, then altering VOStore contents without informing VOSpace is 
going to cause problems.

> 
> Access control:
> -------------------
> 
> A VOStore can run in two modes: authorized and unauthorized. An 
> unauthorized VOStore is semantically equivalent to an anonymous ftp 
> site: any authenticated user (we still maintain security) can put 
> something in, move/rename it, get it and delete it.
> An authorized VOStore will only allow the requested operation if a valid 
> authentication token is included in the request - all the VOStore has to 
> do here is validate the authentication token. The generation of the 
> authentication token is handled by VOSpace: it makes sure that the 
> authenticated user has permission to do what they are requesting and if 
> so, places a valid token in the request down to the VOStore.

I think that this is a good scheme - however, is there to be a 
validation token per file or per VOStore?

> 
> Identifiers:
> --------------
> 
> The protocol identifier ivo:// identifies a resource that exists in the 
> VO. It does not promise that you can completely resolve a URI beginning 
> ivo:// in a registry, merely that some component of the URI will relate 
> to a resource that has a registry entry, i.e. the bit before the first # 
> can be resolved in a registry. So I can go to a registry and find out 
> where ivo://nvo.caltech/vostores/vostore1 is
> but I need to go to VOStore interface for this store to resolve 
> ivo://nvo.caltech/vostores/vostore1#halibut3. I do not see why we need 
> to introduce a second protocol just for VOStore contents.

Introducing a new URI for vostore is not absolutely necessary, as you 
demonstrate above, you can invent any interpretation of the ivo: URI 
that you want, however, a separate URI scheme does have the benefits of

    * reducing complexity of client software that has to interpret VO
      URIs/URLs - they can make simple decisions based on string syntax
      rather than having to constantly query registries, which could
      become a performance issue.
    * adhereing more closely to established URI/URL manipulation
      conventions - the # character normally denotes a "fragment" of the
      referenced resource - it is arguable whether this useage is a
      fragment.

We also need to consider carefully whether it is simply an identifier 
that is needed, or a locator, and indeed whether there need to be 
different schemes at the VOStore and VOSpace levels - for VOSpace URIs 
in particular there are questions which we potentially ignore by 
insisting that everything is in the ivo: scheme e.g.

    * do we want a single global authority?
    * do individual user's homes have separate roots in the namespace or 

      are they just part of the directory hierarchy?
    * are relative URIs meaningful?

Another argument for a new scheme is that it has been suggested that it 
would be nice to be able to reference fragments of the stored entity - 
e.g. parts of a VOTable - the ivo: scheme is already rather overburdened 
to allow this extra level of specification.

> 
> Now resolution of individual VOStore identifiers has to be done at the 
> VOStore level; however, VOSpace gives you the ability to set up a single 
> logical identifier for multiple copies of the same resource so here we 
> might want a separate protocol: vos and resolution of this identifier 
> has to be done at the VOSpace level since VOSpace manages multiple 
> VOStores.
> 

I think it is essential at least to have a new scheme at the VOSpace 
level ;-)


-- 
Paul Harrison
ESO Garching
www.eso.org