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