AG: FileStore is dumb and FileManager has all intelligence (incl who owns items)
coffee discussion
need layer above FileStore to implement security
VOBroker
but AG could just plug this into its FileStore --> VOStore
Dave's FileManager presn
do we want to introduce replica management into the spec at this stage
for now, AG only implements http protocol for filestore
but could implement other protocols
need to define minimum set of protocols
if http, need to ensure security
need protocol negotiation
minimum:
SOAP with DIME attachment,
HTTP
needs to allow security
VOSpace will support N protocols
will address many underlying filestores
client agent can state which protocol it wants to use
VOSpace will only pass back stores which support that protocol
Guy's Security presn
Wil: users don't care about how security is implemented
Guy: implementers of VOStores will
SAML as language for tickets?
yes, but not only option
issue of which tickets are needed for an activity
requires policy store/check
look at Shibboleth / PERMIS
Later discussion
decided we do not need to standardise on VOSpace for now, just VOStore (see Agreements below)
Roy's Use Cases
Collaborative shared space A geographically-separated group is working on image-cleaning algorithms. Each member of the group can see the results from others and uploads the images they have built. The group can (if they wish) allow only group members to see the images.
Distributed file system A group can share data objects with each person using the client they prefer. Some like Linux, some Mac, some Microsoft. They can mount a filesystem, they can use a web browser, they can use scripted command line.
Object Listing To see a listing of all the data objects that are in the VOSpace owned by a given user or group, together with metadata such as size, mime-type, date, permissions, etc.
Asynchronous services A scientist uses NVO services asynchonously, so that results do not come back to the client as a service response packet, but rather they are put into VOStore. The results can be picked up later through a variety of client tools.
Workflow A user wishes to connect NVO services in a sequence, so that the output of one is the input for another. This can be implemented if one service writes a data object into VOStore, passes a VOStore reference to the other, who can then read and use the data object.
Distributed CasJobs CasJobs (http://casjobs.sdss.org/CasJobs/) is a browser-based environment for processing database tables. Users get an account, and results can be persisted in the "home space" that comes with the account. We would like to have geographically-distributed servers, so that a user sees the same home space whichever server is being used.
Widening the permission A user has created a private data object in a VOStore, and wishes to make it available to a wider audience by changing the permissions.
International A scientist has created a data table on the Astrogrid "MySpace" system, and would like to crossmatch it with another table that is in the NVO VOStore system.
Telecon
Agenda
run through discussions and agreements of meeting
use cases
VOStore specifics for:
WebDAV
SRB
Notes:
re VOStore data return format
?whether need this in the capability definition
three layers: VOStore, VOSpace, physical
will only standardise on VO levels
subset or views of data
cannot include parameters in name of item
could do this by defining view name as item and change the view in the underlying database by another means
naming
will use ivo://vostore_registry_id#vostore_identifier
Alternative: use endpoint of VOStore service instead of IVOID above. This would be problematic if using http as endpoint as cannot then discern web service from http; not recommended.
resolve AG ivorn
look up bit before # in registry and find service
send service bit after the #
creating data item
do we allow space reservation
transport protocol
must support http put/get
security, identification, authentication
identity of person
can use ivoa identifier for community and look up user with id after #
can use certificates to sign into portal but back end authentication using tickets
tickets are signed SAML assertions
like proxy certificates
Meeting Agreements
these are subject to agreement with NVO team
still only need VOSpace and VOStore layers
VOStore is higher level than AG FileStore
do not need VOSpace protocol at this point
just need common definition of VOStore
includes list method
includes callback api (to know when asynch action finished)
projects implement own VOSpace
will look to standardise afterwards
VOStore will advertise its capabilities (metadata in registry)
eg ability to return data in given format
AG filestore (currently) will only return in format uploaded
AG will extend filestore to support VOStore
MyDB will allow return in VOTable, CSV, FITS
ticket-based security looks like way to go
subject to trial (see below)
Telecon agreements
will not include ability to reserve space in VOStore
can be added to V2 later if necessary
all VOStores must support http put/get as a minimum transport protocol
will only work at data object level (not lower than that)
Action list
Wil: send Dave latest version of VOStore: end of this week
Dave: update VOStore doc with new methods: before May Interop
synch/asynch
init & data
get & put
Guy/Wil: get prototype security mechanism working: before May Interop
Dave/Wil: add Roy's use cases to VOStore document: before May Interop