Notes from the weekly DAS/2 teleconference, 10 Nov 2005.

$Id: das2-teleconf-2005-11-10.txt,v 1.1 2005/11/12 00:48:39 sac Exp $

Attendees: 
  Affy: Steve Chervitz, Ed E., Gregg Helt
  UCLA: Brian O'connor
  CSHL: Lincoln Stein
  UCBerkeley: Suzi Lewis
  Sweden: Andrew Dalke
        
Action items are flagged with '[A]'.

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

Agenda Items
------------

* New Euro-friendly meeting time

It was decided to change the time for this weekly teleconference to 
Monday 9:30 AM PST (12:30 PM EST, 17:30 UK). 

[A] New teleconf time starts next week (Monday 14 Nov)

* Spec Issues

Gregg expressed a need to dedicate some of these weekly meetings to
be focused on resolving spec issues. We will do this for next week's
meeting. 
[A] Everyone come prepared to talk about retrieval spec issues on 11/14.

Content-type issue:
 - Should we use text/xml or application/x-das-blah+xml? 
 - Consensus: use application/x-das-blah+xml
 - [A] Steve will rollback changes made to the retrieval spec.
 - Andrew acknowledges that text/xml may be handy for visual debugging
   and other presentation tricks, but is not a user-driven need; 
   it's a technical issue.
 - Lincoln: XML handling is very browser-dependent:
    o Firefox - nice DOM tree structure
    o Safari, Konqueror - no special rendering
    o MSIE - "Cannot be displayed"
 - Gregg: Now we just need to ensure that we're actually implementing
   the correct content-type for given responses, which brings up the
   next topic...

* Validation

 - Gregg: we'd like to start using dasypus locally to verify
   client/server compliance with the spec. What state is it in?
 - Andrew: Just getting back to it now.
   [A] Andrew will talk with Chris D. to set up a web interface at biodas.org

* Apollo

Suzi: Can't talk about Apollo now. Will wait until Nomi is available. 
[A] Nomi will present Apollo at the 28 Nov DAS/2 weekly meeting. 

Status Reports
--------------

Gregg:

* CSHL Genome Informatics meeting summary of DAS/2-relevant things.
 - Gave talk about DAS/2 and demoed IGB. Went well.
 - Held a DAS BOF that was well-attended (n=15). 
   Questions people had about DAS/2 have already been addressed.
   [A] Gregg will write up his CSHL DAS BOF notes and post.

   Discussion centered around what Sanger & EBI are doing with DAS.
   o There are lots of DAS-related projects there.
   o We'd like to have tighter linkage between DAS folks in the states
     and those in the the UK.
     [A] Andrew will visit the UK DAS folks more often.
     Ideas:
     + Help them transition to DAS/2
     + Hold "DASathon" or jamboree there
   o People: Tim Hubbard, Thomas Down, Andreas Prlic
   o Projects: 
     + Serving up 3D structures using modified DAS/1 server (SPICE)
     + Serving up protein annotations using modified DAS/1 server
     + Registry & discovery system for DAS/1 server
       This is SOAP-based. We'd like to have a non-SOAP-based system
       for DAS/2, which follows REST principles.
       - Andreas could likely create an HTTP-based alternative to his
         SOAP system, which uses the same core.
       - [A] Andrew will talk with Andreas P about non-SOAP reg/discovery
       - [A] DAS/2 grant needs progress on reg/discovery w/in next 6 mos

* Grant (DAS/2 continuation)
  Lots of modifications were made just prior to submitting on 1 Nov. 
  Some of the changes include:
 - Work closely with Sanger and EBI where they've done lots of work
   (3D structure and protein DAS).
 - More of a mechanism will be in place to drive the spec forward:  
   o Andrew = designated 'spec czar' - makes ultimate decisions
   o Lincoln = designated 'spec godfather' - retains veto power
   
Andrew:

* Brought up the header issue from the spec discussion on the list
  this week. 
 - Doesn't like the idea for 4 additional DAS-specific fields
    (error code, das version, server name, and something else)
 - Alternative: server returns content-type: application/x-das-error
 - Advantages: 
   o no new header
   o simplified header -- just check the http error code in the
     content-type. 
   o easier to implement
   o enables a flatfile-based server
   o Fits with REST philosophy of using HTTP as an application
     protocol, not a transport protocol.
 - Ed E: Can't we just return an error section in the document?
   Andrew: We could, but it requires parsing the document and only
   works for XML formats that we're in control of.
 - Gregg: The advantages of having metadata in the header outweighs
   the advantages of enabling a flatfile-based server.
   Andrew: We can utilize the existing header
   Ed E: Piggybacking error codes causes problems with proxy servers
   (see email on the DAS/2 discussion list).
 - Decision:
   [A] Use standard HTTP error codes; use XML to specify error details.
   E.g., server status=200
         content= error document
   Steve: When reviewing spec, encountered potential issues surrounding
   relationship between HTTP and DAS-specific error codes. Using
   standard HTTP codes will obviate this issue. 
   Also noted that there's a bugzilla entry regarding error codes
   (which is now moot):
   http://bugzilla.open-bio.org/show_bug.cgi?id=1784
 - Ed E: MSIE hides or modifies content based on certain HTTP error
   codes it gets. This has important implications on windows platforms
   where IE's behavior can get in the way of other network-aware
   applications that don't even (knowingly) use IE.