[DAS2] Fwd: DAS Writeback Summary
Steve_Chervitz at affymetrix.com
Tue Dec 14 01:44:45 UTC 2004
Begin forwarded message:
From: Ed Griffiths <edgrif at sanger.ac.uk>
Date: September 28, 2004 5:43:56 AM PDT
Subject: Todays meeting.
I have attached a summary and a fuller set of notes about where we seem
got to. [inline below]
There is a lot of work to do in formalising and filling out the details
seem to be making some progress.
| 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:
we need to sort out the mailing lists, its clear that there is a lot I
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
meetings and by when ?
Is there a reference server set up that we can all try or copy to our
In this write up I've marked with a ** some of the issues we should
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
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
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).
- we have decided that we will only allow locking on regions, not
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,
genes that not located get editted etc. etc. ?
- we decided that unless an object is fully contained within the locked
then it is not locked. If the user wants to edit that object then they
extend the region that they want to lock to include that object.
- the lock request is POSTed to a new URL, listed in the data source
and probably named something like .../lock/new. The request will include
things like name (or is that provided via some other authentication
region to lock, and time for lock. If no error, the return includes the
URL (probably something like ".../lock/lock12345"), and length of time
- a GET on the lock URL returns info about who locked it, the time
for the lock, and region
- There should be a request that allows the client to find out from the
which regions are already locked so that annotators can be given this
information before they request a lock. (the data source document will
include a URL used to get the list of current locks)
- There will be a request which allows the client to find out which
edittable on a per user basis, this will allow the annotator to see in
what they are allowed/able to edit.
- There will have to be authorisation for each lock/edit operation. It
assumed that all this will be straight forward as database
authorisation via http are known and solved problems.
- a POST of some sort to the URL is used to renew the lock, commit the
or revert the transaction. We think it should also be able to expand
- breaking locks is outside the scope of the spec. Eg, it might only
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
** What we do need to decide is on how a client asks for a specific
** a feature, or even if this is possible ?
- locks will have timeouts (when a lock is granted, the response will
the client how long the lock will be held for).
- the timeout period is for "idle" time, not total time.
- 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",
- should be providing a mechanism for a client to verify that changes
been successfully committed in this case ?
- Andrews investigations imply that caching will not be the problem we
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
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
shouldn't include password information to publicly accessible data as
won't be cached.
- versioning of features is currently responsibility of the database
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
More information about the DAS2