pharriso at eso.org
Thu Aug 4 02:56:09 PDT 2005
Matthew Graham wrote:
> 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?
> 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
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
I think it is essential at least to have a new scheme at the VOSpace
More information about the vospace