[DAS2] Notes from the weekly DAS/2 teleconference, 8 May 2006

[Steve Chervitz]

Notes from the weekly DAS/2 teleconference, 8 May 2006

$Id: das2-teleconf-2006-05-08.txt,v 1.1 2006/05/09 01:43:17 sac Exp $

Note taker: Steve Chervitz

Attendees: 
  Affy: Steve Chervitz, Ed E., Gregg Helt
  Dalke Scientific: Andrew Dalke
  Sanger: Andreas Prlic, Roy
  UC Berkeley: Suzi Lewis
  UCLA: Brian O'connor

Action items are flagged with '[A]'.

These notes are checked into the biodas.org CVS repository at
das/das2/notes/2006. Instructions on how to access this
repository are at http://biodas.org

DISCLAIMER: 
The note taker aims for completeness and accuracy, but these goals are
not always achievable, given the desire to get the notes out with a
rapid turnaround. So don't consider these notes as complete minutes
from the meeting, but rather abbreviated, summarized versions of what
was discussed. There may be errors of commission and omission.
Participants are welcome to post comments and/or corrections to these
as they see fit. 



Topic: Writeback
----------------

[A] Andrew will find out status of biopackages server re: writeback

Topic: Stylesheets  (we'll return to writeback later...)
------------------

ad: stylesheet spec is out. see recent email post.

roy: similar to z-map approach, not too much different.

ap: you have a link to type. below you provide how you want to
draw. if you have a line, you can also have a wireframe, cartoon,
spacefill. Allow a list of elements that you want. Client can choose.

ad: for structure we might want to have a set up where most of
residues are in one depiction, some subset of residues are in an
alternative depection (e.g., active site residues are
spacefilled). How would this be addressed? (currently an open question)

[suzi joins.]

gh: getting back to writeback. suzi's feedback. plans for apollo.

sl: no resources at the moment. we have a proposal just for apollo RSA
for development. chances are not as good for funding. P. good
recommends bundling with das and submit a das grant.

gh: pushing back application a month or two to give gh a chance to
revise it. a good idea.

sl: the plan is to give us a more time to reivse das grant.

gh: given that there's no work on apollo writeback, looking at adding
this functionality to igb.

sl: what about pirating some apollo stuff for editing for inclusion
into igb?

gh: more detail in apollo. merge, split, etc. are in igb now in
prototype form. Looking at working on this to get some primitive
writeback before end of current grant cycle.

we may need to put more emphasis on cross client interaction.

sl: love the idea, but reviewers didn't think it feasible.
if we do cross component communication, the bulk of the work is
getting enough forward progress to make a more persuasive case in the
proposal. 

gh: resubmitting date? july?

sl: talk to p. good. july will be difficult for me. out of country.

gh: plan is for suzi to be PI.

sc: date? 

gh: need to get in touch w/ peter about this. to get renewal status
there is a time frame.

Topic: writeback (continued)
----------------------------

ap: if a feature is deleted and new is created, how to know the
history linked to new feature? similar to discussion andrew fwd to
list. didn't see any conclusion.

ad: there is no conclusion for it. the details are server dependent. a
server the impl history tracking can post to the feature itself.

sl: if it's deleted, it's deleted. this isn't an undoable delete is
it?

gh: grouping the changes. within the post, you have a grouping so you
are merging two things, they are encapsulated w/in a change element.

ad: orig idea was one big delta doc, including all feats add, modify,
deleted. But you want to track things more closely. proposed a delta
doc that groups things. then proposed a micro delta - these features got
merged,... and a remark statement. why the merge happened. conceptual.
whole writeback is a list of microdeltas.

people that impl feature history do it as they want to. extension to
feature. could also do it via another request.

server could track of everything that happened on server. track all
history if it wants to.

[see andrew's email for more information about this.]

gh: andrew should touch base with allen and brian progress on
biopackages server. if you can impl something in a few days go for it.

ad: like the in-memory database approach.

gh/sl: fond of this approach.

roy: favored sending back a mapping document.

ap: this features follows up some features (uri) that has been
deleted. permits link from new to old feature.

roy: post data to server, server replies with same document, modified
according to what the server has done. has to do work to redraw,
rather than have mapping doc that goes from and to, that info is in
the features themselves.

ad: my mapping doc, forces client to figure out what the new feats
are. your approach means less client work.

roy: client can't toss everything if you're sending a delta across.

ad: just everything that's changed.

gh: did you send email about this?
roy: just to andrew. can post to the list.

[A] roy/andrew will forward message re: writeback to the list

ad: like the idea of keeping feat element exactly the same. willing to
be less pure about it.

roy: think of it as extending the read-only server. extending the
feature as well.

[A] andrew will change spec to respond with a full feat doc for feats that
changed.

roy: only changes that the client sent.

ad: if the db is handling intra link (xid) pointing else where in the
database, and the pointed to feature disappears, the server could
update other features that pointed to those disappeared features.

sc: that might confuse the client that gest feats back it doesn't know
about.

ad: but the client might then get out of sync with server.

roy/gh: worry about this

ad: we can defer until issue arises (if it does)

roy: error state for spamming a server, i.e. hitting a server again
and again with same info. indicating that the client isn't getting the
response from server.

ad: client has to detect error and reload from the db.

roy: nice to be stateless.

ad: ask server for url. can put or post to it. if fails try again,
then you can read from it to see if your submit worked.
Example: 
ask server for ftp url.
ftp it over.
check it.
tell server it's there, process it.
you never get duplicates.

roy: this touches on locking.

gh: other than locking, not sure what state we need to maintain.

ad: other issue: authentication.

ap: this could be done by web server.

ad: which http authentication are we going to standardize on? async,
basic (passwds sent in clear). I propose we talk about it next week.

[A] we will talk about authentication next week (5/15).

ad: issues: improperly coded client. network going down (client can
reload from server).

gh: client never got response, so it will know .

ad: inside header, have location, if it got a partial download, it can
go and re-fetch it.

gh: should definitely be optional if it is in there.

ad: spamming question: a poorly impl client, posting the same thing
again and again.

ap: shouldn't locking prevent this?
gh: if same client, then no. not sure how bad that would be if
nothing's changed. how would that mess up the server?

ad: would depend on how server is impl.

gh: possible multi-threading issues - the mapping info may get out of
sync. I would put in as a recommendation in the spec that a client
wait until it gets a response from server before it sends another one.

ad: so fifo order processing.

[A] andrew spec mod: client should wait for server response before sending
another update request

ad: error handling. the error response document will be handy
here. figuring out why something failed.

gh: to me it seems unlikely that there will be clients that do
anything other than pass through the error info. that a client will do
anything interesting with the error response other than just show it
to the user.

Other topics:
--------------

bo: questions about igb. we can talk later. don't know status of
writeback right now. Check with Allen.

gh: status of registry?

ap: have dev servers that aren't publically available. have been busy
with other projects. das/2 working now on his private dev
server. waiting for server box. works - to retrieve a list of das sources.

the machine has little memory.

[A] Steve will send andreas link to versioned sources command for Affy das/2
server

[A] next week prepare to cover more details on writeback impls.