[DAS2] DAS writeback (fwd)

[Roy Storey]

All,

As requested during the conference call here's the mail re full features 
in the response.  What this does do is make the mapping explicit, making 
immediate history a property of each feature.  During the writeback action 
a client should in theory be able to "remove" the features it's saving and 
use the response as if it were a GET/query.  There is less issue with 
having to look up features using one key/uri and change to another, as 
would happen using mapping.xml response.

Regards

Roy

---------- Forwarded message ----------
Date: Thu, 27 Apr 2006 11:37:32 +0100 (BST)
From: Roy Storey <rds at sanger.ac.uk>
To: Andrew Dalke <dalke at dalkescientific.com>
Cc: allenday at ucla.edu
Subject: Re: DAS writeback

Andrew,

Sorry for not getting back on this yesterday, and as I've not really been able 
to keep 100% up to date on the DAS2 state of the art, apologies if I'm 
repeating previous discussion.

On Tue, 25 Apr 2006, Andrew Dalke wrote:

> Have you had any thoughts on this?

A few, nothing concrete.

> Mine is that a single POST using a private namespace is the
> right solution.  It makes for simpler servers and the client
> overhead isn't really that much.  What I like the most is the
> support for multiple versioning models, like "modify in-place"
> vs. "keep old versions"
>

This is about what we'd agreed in Feb. An editing client can hold objects wich 
are new and unsaved keying them how ever it wishes.  On saving these to the 
server, the server can respond with a mapping document between client ids and 
server ids.  The client then has the simple task of moving the objects from 
it's new unsaved objects list to its up-to-date objects list, applying the 
correct key translation as it does so.  As you said this works well for 
modifying current features and adding versions as well.


So what on splitting and merging?

This brings me to Otter, which rather than just replying with a simple mapping 
document, actually sends the complete features which are the result of the 
modifications.  I just wonder what the feeling for this is.

So a feature starts life in an editor...

uri="das-private:$md5_feature_bits"

gets saved to the server

somewhere in response
<feature uri="http://das2server/feature" >
   <previously uri="das-private:$md5_feature_bits" />
   ...
</feature>

get merged/split & saved

somewhere in response
<feature uri="http://das2server/another_feature" >
   <previously uri="http://das2server/featureA" />
   <!-- possibly, in case of merging -->
   <previously uri="http://das2server/featureB" />
   ...
</feature>

Ok so there are likely some issues with this, but I thought I'd raise as it 
could unify rw/ro and remove the need for mapping.rnc, which although I like 
does feel a tiny bit dirty. The first obvious problem with the above is it's 
more extra work for the server to do to output a single feature, so just on 
this feel free to shout me down.  It's possibly open to abuse too.  I also have 
mixed feelings on whether the spec should dictate how to do these more complex 
operations.


So a couple of what ifs:

- The client fails to do the mapping/moving.

This will result in the new feature being kept as "new" although the server 
knows about the feature.  This is likely to result in duplicate features on the 
server, as next time the client saves it'll send a "das-private:identifier". 
If the server is keying features on enough information to distinguish this IS a 
duplicate then the writeback will fail and this isn't an issue, except for the 
client author.  However, if the "new" feature stays as new, gets modified and 
saved again, then the possibly wrong features will just accumulate.

- The server doesn't send a complete response (dies/gets rebooted).

Only some of the features get "moved" in the client (See above). In this case 
though the client should/will know that something isn't right and should 
probably do a re-fetch of all the features, which will result in having to 
remove from the "new list" features which have been saved, but this seems sane 
to me.


Roy