[DAS2] Fwd: DAS2 server registry and discovery meeting, Friday at 10 AM

[Steve_Chervitz]

Begin forwarded message:

From: Andrew Dalke <dalke at dalkescientific.com>
Date: September 23, 2004 9:49:59 PM PDT
Subject: Re: DAS2 server registry and discovery meeting, Friday at 10 AM

Steve:
> It would be helpful if someone could circulate notes summarizing
> the discussions, conclusions reached, and any action items (especially
> for us West-coast, non-morning types ;-).  Thanks!

Ughh!  I made it for the 10am BST conference call two days ago.
I'm still recovering ... :)

Here's my summary of the two conference calls.

The first day we went over the draft version of the protocol.
We made some minor changes, mostly to clear things up and fix
typos.  The biggest changes were in the document that returns
information about a data source, and we're getting rid of the
'sequences' section, to use 'region' instead.  (The document
had a bit of both.)

I think the only action item there is that Lincoln's going to
update the spec and redistribute it and I'll go through it with
my fine toothed comb.

This morning (my time) we talked about updates.  There are
many ways to do it.  One is via WebDAV, but none of us really
have any experience with it.  I've read the spec which made
me the most knowledgeable.  The thing about DAV is that it
requires several new HTTP level commands, like LOCK and
PROPFIND.  DAV seems to provide mechanism but not policy
and without some experience we decided to pass on it for
this version.

I personally would like to encourage people in the community
to experiment with that technology.

We talked about various ways to send updates, starting
with how people do it now.  I didn't follow this part well
enough to report it now but it seems that the client sends
basically a diff as one document.

The next topic was locking.  We can support optimistic
(CVS-style) or pessimistic (RCS-syle) locks.  In other words,
don't lock until it's time to commit changes vs. lock when
making the first change.  CVS-style is interesting, but
it makes lock conflicts harder to deal with.  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.

Though again I would like to encourage people to experiment
with, say, SVN as part of a back-end versioning system
layered on top of WebDAV.  The tricky parts are maintaining
internal consistency of all the independent branches and
handling branch merges in both client and server.

The conclusions in the locking discussion are:
   - pessimistic locking on a region specified by the curator.
      We will not support locks on a specific feature, feature
      type, etc.

   - 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 include 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

   - 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.

   - the data source document will also include a URL
       used to get the list of current locks

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

There was also some discussion about how a client might
show to the curator which elements can be edited.  Currently
that's known through extra-protocol means (ie, by talking
to people and reading the documentation).  It might be
nice if the client tool could make some sort of indication.

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.

(Which reminds me, the DAV spec also support the HTTP
operations of MOVE and COPY.  These allow the versioning
system to keep version information even after splits and
renames.)

Did I omit or misstate anything?

					Andrew
					dalke at dalkescientific.com