VOSpace development : things still to do -- DaveMorris - 17 Jul 2007

Moved the contents of this list to the VOSpace Trac system.

Delete temp files

Delete temp files when they are released. (1 day)

Connect temp files to the session, and delete them if session.rollback() is called. (1 day)

Service registration

Not addressed this one yet. Need to learn new registry syntax and create a generator (probably a JSP or Cocoon page). (unknown)

Service ivorn(s)

One 'server' deployment may provide more than one 'service'. The ivorn for each service is generated from system ivorn plus the ident of entry point node. (1 day)

ListViews^?

Currently only a stub (required for IVOA interop). (later)

ListProtocols^?

Currently only a stub (required for IVOA interop). (later)

ListNodes^?

Refactor handler for paged data to create a ListStatus^? object in the database (ident becomes the token). ListStatus^? keeps track of what has been sent so far, and Hibernate query controls the number of results in each response. (2 day – assuming Hibernate works as advertised)

Add support for wildcard search (this is part of vos 1.0 and forms the basis for tree handling in 1.1 interface). (2 day – assuming Hibernate works as advertised)

There are still some issues with lazy loading of database objects. In the long term, the object to relational mapping may need to be refactored to enable this to handle large datasets. This can be optimised later, as the server side API hides the database structure from the rest of the code. (later).

CopyNode^?

Need to implement the copy node method, including copying data files and a recursive copy of children. (1 day)

Simple copy just duplicates the file on disk. There is the potential for “copy on write”, by allowing more than one Node to link to a File. Would need some (minor) refactoring of the object model to achieve this, major advantage if we could. (later)

MoveNode^?

This is already implemented in the database code, but not connected in the Axis service. (1 day)

HttpTransferServlet^?

A simple servlet very similar to the local file handler already used in testing. Handler registration and configuration could be better, but current static global works for now. Servlet should be able to be deployed in separate webapp, using the servlet config to acces the vospace configuration data. (2 day – Test set up and deployment will be the major factor in this)

Filestore properties

(this refers to the disk based filestore backend in vospace, not the current FileStore^? web service) Total size quota added to the filestore. Node files can be checked for size when they are adopted. Temp files may be checked, but less rigorously. (1 day)

Admin pages

Admin pages to configure system, e.g. Service ivorn etc. Admin pages to generate service registration Admin pages to configure transfer servlet and handler. Admin pages to create and manage local filestore(s). (5 day – most of the work will be design)

Node properties

Add basic properties like “data size”, “last modified date” and “owner”. Property handling code is already in the database system, but need to add specific server generated properties that users will expect to see (plus registration of the standard URIs). (1 day)

Adapting the Axis handling of xsi:nil for deleting a property. The default behaviour of the axis tools hides xml specific attributes like xsi:nil from the service back end. Adding an explicit xsi:nil attribute to the service wsdl should make the Axis tools pass this on the the service implementation, enabling the servier to delete the property. (1 day)

Access control

Identity in messages, ownership of nodes, and checks to enforce permissions on actions. Code structure based on context and actions explored in metagrid, using a standard interface to determine 'is allowed on . Initial permissions would be “owner rw, other r”, but using an abstract interface that allows complexity of ACLs to grow later. Most of this is already on paper or in experimental code elsewhere, but been a while since I looked at it in detail. (10 day - not required for initial myspace replacement)

Update SOAP/WSDL interface

Need extensions added to handle tree and links. Adding new node types and exceptions in the right places. Not expected to be a major problem, but this will form the basis of the vospace 1.1 proposal. (2 day)

Security

Integrate the SOAP service with the Axis handler from the AG security component. This will enable us to distinguish who is sending the message. This has been done before, and the Axis certificate handler is fairly easy to use. Figuring out how to set up the test environment will be a major factor in this. Need to be able to test this without having to grant the test system full grid certificates. (5 day – several unknowns)

Http transfer client

Refactoring of the existing FileStore^? client code to get and put data via http. (1 day)

SOAP delegate

Simple delegate that wraps the SOAP stub, but additional code will be needed to wrap protocol negotiation to produce a clean delegate API. (5 day)

Delegate resolver

vos://vospace URI resolver, using registry client to resolve the service endpoint and return a delegate that connects to the service. Simple form can use existing code from other components, but handling multiple capabilities will need new code. (2 day – depends on solving service registration)

DSA client

Stream based API, opens an OutputStream^? to a vos://vospace URI. Destination view is votable or binary file. Based on delegate resolver and http transfer client to send and receive data. (2 day)

CEA client

File based API, fetches the contents of a vos://vospace URI and stores it in a local disk file, sends the contents of a local disk file to a vos://vospace URI. based on delegate resolver and http transfer client to send and receive data. (2 day) Option to specify the target view, but would require changes to CEA in order to make use of it. (later)

VOExplorer client

Apache VFS handler for vos://vospace URIs. Resolve vos://vospace URI into a VFS file, interpret actions on VFS file as messages to the vos service. Uses delegate resolver and http transfer client to send and receive data. This will eventually become the main client delegate for all applications, including CEA and DSA. (10 day - Based on Noels implementation of ivo://myspace handler)

Myspace service interface

Implement a myspace webservice which connect to the vospace database back end. providing a migration path from myspace to vospace systems. (10 day – several unknowns)