Re: VOStore interface

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