[DAS2] Fwd: DAS Writeback Summary

[Steve_Chervitz]

Begin forwarded message:

From: Ed Griffiths <edgrif at sanger.ac.uk>
Date: September 28, 2004 5:43:56 AM PDT
Subject: Todays meeting.

All,

I have attached a summary and a fuller set of notes about where we seem  
to have
got to. [inline below]

There is a lot of work to do in formalising and filling out the details  
but we
seem to be making some progress.

Ed
--  
   
------------------------------------------------------------------------
| Ed Griffiths, Acedb development, Informatics Group,                    
  |
|        Wellcome Trust Sanger Institute, Wellcome Trust Genome Campus,  
  |
|               Hinxton, Cambridge CB10 1SA, UK                          
  |
|                                                                        
  |
| email: edgrif at sanger.ac.uk  Tel: +44-1223-494780  Fax:  
+44-1223-494919 |
   
------------------------------------------------------------------------


An aside:

we need to sort out the mailing lists, its clear that there is a lot I  
and
others haven't seen. Should we be using a restricted mailing list or....

actions: who is going to put the DAS2 spec together as a result of all  
these
meetings and by when ?

Is there a reference server set up that we can all try or copy to our  
own
locations ?


In this write up I've marked with a ** some of the issues we should  
discuss.


=================================================================
DAS 2.0 Write Back

HTTP protocol issues
--------------------

- we have decided not to use webdav in this DAS2 version.

- we need to decide how our DAS2 requests map to the http  
GET/POST/PUT/DELETE
commands.

e.g. we have not yet discussed how we're going to do the actual  
editing.  It might
be by PUT/DELETE calls on the elements, or through a unified diff  
POSTed to
the server which contains a list of all the changes.

- in particular we need to decide what we pass between server and  
client in the
way of authentification and state (e.g. locks).



Locking
-------

- we have decided that we will only allow locking on regions, not  
features.
The client can specify start/end coords for regions.

- Note that this implies that we only lock _locatable_ objects, this is
something we need to explore further, e.g. how do "types" get editted,  
how do
genes that not located get editted etc. etc. ?

- we decided that unless an object is fully contained within the locked  
region
then it is not locked. If the user wants to edit that object then they  
have to
extend the region that they want to lock to include that object.


Lock operations

- the lock request is POSTed to a new URL, listed in the data source  
document
and probably named something like .../lock/new. The request will include
things like name (or is that provided via some other authentication  
means?),
region to lock, and time for lock. If no error, the return includes the  
lock
URL (probably something like ".../lock/lock12345"), and length of time
actually granted.

- a GET on the lock URL returns info about who locked it, the time  
remaining
for the lock, and region

- There should be a request that allows the client to find out from the  
server
which regions are already locked so that annotators can be given this
information before they request a lock.  (the data source document will  
also
include a URL used to get the list of current locks)

- There will be a request which allows the client to find out which  
types are
edittable on a per user basis, this will allow the annotator to see in  
advance
what they are allowed/able to edit.

- There will have to be authorisation for each lock/edit operation. It  
was
assumed that all this will be straight forward as database  
authorisation and
authorisation via http are known and solved problems.

- a POST of some sort to the URL is used to renew the lock, commit the  
changes
or revert the transaction.  We think it should also be able to expand  
the
locked region.

- breaking locks is outside the scope of the spec.  Eg, it might only  
be done
by people who can log into the database system.



Versioning (but see later)
----------

We also talked about tracking all change (just like a full-blown version
control system would) but decided again it was too much to deal with  
now.

** What we do need to decide is on how a client asks for a specific  
version of
** a feature, or even if this is possible ?


Timeouts
--------

- locks will have timeouts (when a lock is granted, the response will  
tell
the client how long the lock will be held for).

- the timeout period is for "idle" time, not total time.


Transactions
------------
- it was agreed that transactions should be transparent to the client so
whether the database uses them to commit data will not be visible. This
implies that our protocol for updating must be via single, "atomic",  
http
requests.

- should be providing a mechanism for a client to verify that changes  
have
been successfully committed in this case ?


Proxies
-------

- Andrews investigations imply that caching will not be the problem we  
thought
it might be.

- But one thing to consider though is how we're going to do user
authentication.  Use an existing HTTP username/password scheme or  
something
outside of that?  If ours is independent of HTTP then we have to be more
careful about how to deal with caches.

If ours is based on HTTP and we want to play nice with caches then  
clients
shouldn't include password information to publicly accessible data as  
that
won't be cached.


Data issues
-----------

- versioning of features is currently responsibility of the database  
but we
may need to provide something to say "give me the latest version" ?

- the client can find out which feature types can be editted for any one
user and hence can show this to the annotator.

- the annotator can edit features on a sequence but not the sequence  
assembly
itself.