VOSpace Brainstorm Meeting

This is a set of notes made during a meeting to brainstorm ideas on VOSpace. Those present in the meeting were:

• WilliamOMullane, GuyRixon, KeithNoddle, Dave Morris, NoelWinstanley, TonyLinde

and on the following telecon:

• RoyWilliams, JohnGood, MatthewGraham

See also:

• http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/vostore0.15.pdf

Presentations

• MySpace structure & scenarios (Dave Morris): FileStore.html, FileManager.html
• Security aspects (GuyRixon): ppt, pdf

Notes

Dave's FileStore presn

• in Export: MIME type allowed for data conversion (eg FITS to jpeg)
  • as yet no negotiation
• question of about how dumb is the VOStore
  • contains metadata per item but does not interpret them
  • but must do so to implement security
• MyDB vs MySpace:
  • MySpace returns exact file put in
  • MyDB will translate into database and back again
  • so need to include flag that says 'store exactly'
• VOSpace vs VOStore
  • Wil: implement only VOStore first
  • 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)

Telecon

Arguments

• whether we need transformation (RESOLVED with VOStore capabilities)
  • mandatory if you are putting from file to database
  • metadata must indicate capabilities of store

Agreements

• 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
  • 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)

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