[DAS2] DAS/2 weekly meeting notes for 21 Nov 05

Mon Nov 21 20:15:41 UTC 2005

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

$Id: das2-teleconf-2005-11-21.txt,v 1.3 2005/11/21 20:15:28 sac Exp $

Attendees: 
  Affy: Steve Chervitz, Gregg Helt
  UCLA: Allen Day, Brian O'connor
  UCBerkeley: Suzi Lewis, Nomi Harris
  Sweden: Andrew Dalke
  Sanger: Andreas Prlic

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

Today's topic: Client-Server implementation issues
----------------------------------------------------

Suzi/Nomi
---------
  Questions for gregg: How to communicate styles in DAS/2?
  GH: Client gets style sheets from server that suggests how to render
things.
  AD: EBI uses this a lot. Most of the DAS systems there use stylesheets.

  [A] Andreas will contact folks at Sanger/EBI for stylesheet example code.

  GH: The IGB client uses a preference configuration, using java
  preferences rather than special XML file. Windows: sets values in the
  registry. Has been successful. If client can understand DAS/2
  stylesheets and client-side prefs, the client-side prefs should
  override the server styles (others agree).

Steve
-----

* Reported on some analysis of Affymetrix DAS server weblogs. Lots of
  google-bot data download. Lots of spotfire hits, too.  BO: Google
  bots should respect robots.txt

[A] Steve will install robots.txt in the relevant locations

* Reported on getting Greggs DAS/2 server to run on top of apache
  rather than as a stand-alone server. Should be a matter of hooking
  apache up to tomcat using a tomcat connector. Directive for apache
  to defer to tomcat for servlet requests.

[A] Steve will hook up affy das server to apache/tomcat.

Gregg
-----
 * Regarding Spotfire - they are working on a IGB plugin to spotfire
   using http localhost API. This explains our spotfire hits.

   Gregg was previously integrating IGB with spotfire using a java to
   COM bridge. It works, but the COM bridges aren't free etc. etc.
   They are interested in driving IGB from spotfire since they're
   interested in using IGB to provide genome vizualization.  Are
   currently evaluating whether to release it to public or not.  Gregg
   considered putting this in the grant, but would have required
   permission, etc. and time was a factor.  They may eventually commit
   to IGB code base directly, but still need to work out leagalese.
   They will be interested in tracking the interclient API work we are
   doing (IGB-Apollo).

 * No major work on DAS this week, just some niggling IGB issues.

 * Planning another IGB release by end of year that will have
   improvements to DAS/2 clients.  Fixed: access via quickload then
   accesss to DAS/2 causes blankout of screen Fixed: DAS/2 interaction

Brian
-----
 * Marc C has committed stuff to IGB code base (genovis). Is there a
   test suite we can use to verify we're not breaking anything?

   GH: No, but hopefully early next year. Definitely needed.

 * Also checked in the re-factor - separate namespaces for assay and
   ontology. 

[A] Gregg will relocate das2 package to com.affy.das2 & uncouple from IGB

   GH: There are a few igb dependencies to be unraveled
   (das2feature...).  Don't want to do this in the next release
   since that's pretty significant given upcoming holidays.

   GH: Other features to get in:
      * Persistence of preferences.
      * Get rid of hardwiring of DAS2 servers. Already to this for
        DAS/1, just need to replicate for DAS/2.

Allen
-----
 * API for handling ontologies, structures. Communication with Chris
Mungall.
 * Have impl at stanford for autocompletion of ontology terms related to
   samples (Gavin Sherlock's group, SMD).

   What is bioontology group doing for distributing their ontologies,
   what api's are going to be made public?

   SL: Am at stanford right now to talk about that. Will offer bulk
   things like at obo site, but in terms of interactive API, will
   respond to community as best we can.

   Allen: Interested in more integration with bioontology group and
   with his work with SMD.

   Suzi: Not content, but tools right?
   Allen: Yes.
   Suzi: Work with chris. Timing couldn't be better.

[A] Allen will work with Chris M re: ontology API tools for OBO & SMD

* GH: Progress on writeback? Part of grant proposal to get it done by
  june. Will help funding continuation.
  Allen: We could start implementing some of that given the
  refactoring that's now done.

   GH: Ed Griffith at sanger is interested on this. hoping for his
   participation. In the short timeframe, you're server wouldn't have to
   implement it as long as there is at least one server available that
   can do it.

   Allen: Need to look at work load. There's no lack of work to be done
   for get requests (faster impls).
   GH: Would prefer to have just one writeback server and a faster get
   server rather than having two writeback capable servers.

 * Allen: Optimizations involving serving files, kind of a
   report-version of the chado adapters.

   GH: Regarding your rounding ranges optimization for tiling can you
   post to the list?

   [A] Allen will post his rounding ranges optimization to DAS/2 list

   GH: The idea is to help server-side caching by rounding the range
   requests so you're more likely to hit the same URI (e.g., stop=5010
   becomes 6000). Different clients are more likely to hit the cache.

   Not in the spec, just a convention. Requires more smarts in client:
   giving more to the user than they asked for, or throwing out what's
   not asked for. Throwing out what they didn't ask for would be
   nicer. In theory, this won't be an issue with client caching.

   SC: Could make client's configuration re: rounding an option.
   GH: Users want fewer options.

 * IGB display troubles. Allen had trouble getting it to display
   anything besides mRNA
   GH: IGB expects 2-level or deeper annotations. For single-level annots,
   should connect all with a line.
   Allen: May be doing this for SNPs. But also saw some strange
   responses.
   GH: Needs a fix.
   Allen: will it be in next release?
   GH: harder to do it generally -- easier to hardwire it for particular
   data types. Rendering has to guess how deep you want to go.
   Currently goes to the leaves and then goes 1-level up, rather than
   top-down. IGB uses an extra level than you actually see to keep
   track of other things (e.g., region in query).
   Preferences UI: 'nested' can select two-level or one-level deep.
   Would like to hear what others you have problems with..

[A] Gregg will fix IGB display problems for single-level annots.

Andrew
------
 * Emailed open-bio root list to set up cgi for online verifier.
   But no response yet.

 * DAS/1 vs DAS/2 mailing list.

GH: Confusion may occur if we combine DAS/1 and DAS/2 discussion.
Let's keep DAS/1 for all DAS/1 spec related discussion.

[A] Steve verify whether the DAS/1 list is still alive.
[A] Steve will put a link to in on biodas.org for DAS/1 list

 * Locking: Plan to talk to EBI about this in January
   They are doing work for style sheets.

[A] Andrew will ask Ed G. to join these meetings

 * Needs test data, mock data set.

[A] Allen will point Andrew at some data for testing.

Andreas
-------
 * The current registry implementation:
   Written in java two ways to interact:
   1) html, can browser available DAS sources, see details, go back to
      DAS client and activate the DAS source in the DAS client.
   2) soap, client contacts registry, get list of available sources.
   Is open source.

[A] Andreas will post link to source code for DAS registry impl.

   GH: A central registry is good, but companies will want their
   own. eg., at affy there may be 5-7.
   Andreas: It's possible to have a set of registries, local vs. public.

   GH: Are you OK with idea to have an http-based interface? It can
   run on top of existing core.
   Andreas: Sure.

[A] Andreas will provide http-based interface to Sanger DAS registry

Agenda for next week teleconf
-----------------------------
 * Talk more about registry spec issues
 * Retrieval spec issues:
     - Content-type
     - DAS/2 headers
     - Feature and type properties
     - other things?

Andrew: Prefer to have most of the discussion online (DAS/2 list) then
the teleconf can be more productive.

[A] Continue discussing spec issues on the list before next teleconf