[DAS] Question about das development.
Bill Gooding
bgood97@yahoo.com
Mon, 19 Aug 2002 12:42:34 -0700 (PDT)
--0-2142578151-1029786154=:41466
Content-Type: text/plain; charset=us-ascii
To everyone replying to my message,
Thanks for your help, this is the sort of discussion that I wanted to start. On the specific comments:
I am perfectly willing to work with Chris on the development of this software. The one thing I would like to insist on is that it be open source. I am sure that this probably goes without saying in this group :-). We really just need a place to put the project and people can download it if they like. As I said, I have developed a system which is based on JSP/Sevlets/Java. I think it is a good starting point. I am sure you would be surprised if I didn't think that :-).
As for David Kulp's comments, I recognize that the system load may be a problem. But this problem to me would seem to plague any such system. That is, if you are looking at a whole chomosome down to the base pair level, you will have alot of data. I think that this can be addressed by limiting the size of the queries in the server which shouldn't be too hard. Also, the system I have developed, although it is JSP based, it will be very easy to create a standalone program for it so you don't have to go through a JSP server if you want to download and transform alot of data. The standalone program will use the same codebase as the JSP server (which will also allow easy test scripts to be written for the code) This should somewhat mitigate somewhat the load problem.
On your comments about SVG/client integration/Adobe plugins, I really don't want to deal with this issue in the software (if I can avoid it). It seems like it may be problematic to support the plugin and all the browsers that may implement it slightly differently. For now, I think that the user can live with reloading data he needs. I understand this will increase server load. But my vision for this project is not to necessarily create something that would support an extremely high load (at least not at the beginning). I really intend this to be used within a relatively small group of users to simplify the access to data. So in my system, I really want to emphasize customizability. That is, if someone wants to display his data differently he should be able to plugin his XSLT files into the system very easily. I think what I have satisfies that. The advantage of open source would be that people could (hopefully) donate their own XSLT files to the project. This allows for many different views or processing of the data thus giving the users of the software more flexibility. At this point I would see the issue as a tradeoff between speed and flexibility. Maybe in later development any speed problems could be solved or strongly mitigated.
As always, comments on this are welcome.
Thanks,
Bill Gooding
"Kulp, David" wrote:From the whizbang angle, I've been thinking about a DAS-SVG viewer. The
"problem" is typical for genome browser displays: too many features
significantly slows down display, both in terms of data transmission and SVG
client rendering. I looked a little into how one might deal with dynamic
content and semantic zooming. It turns out that the Adobe viewer provides
two non-standard hooks which allow you to make URL calls and to parse the
returning document into a DOM. Thus, javascript callbacks could be attached
to zoom levels, hidden tracks, or objects, which caused the server to be
queried for additional SVG which was then attached to the existing DOM.
Sounds very cool!
But another problem is that SVG (at least with Adobe's viewer) has a
hard-limit of 8 levels of zoom, i.e. a 256X zoom, but unless you're fancy,
it's really just 4 levels of zoom in and 4 out. That's not enough to go
from nucleotide to chromosome.
-d
-----Original Message-----
From: David Block [mailto:dblock@gnf.org]
Sent: Monday, August 19, 2002 10:33 AM
To: Chris Lewis
Cc: Bill Gooding; das@biodas.org; Lincoln Stein
Subject: Re: [DAS] Question about das development.
So close - the author of the first link was at BOSC!
Chris - this Bill Gooding wants to collaborate on an SVG viewer starting
from XML and using XSLT - you guys should be collaborating.
Go for it!
Dave
On Tuesday, August 13, 2002, at 05:51 AM, Lincoln Stein wrote:
> Search for "SVG" and "genome browser" on google. Here's one:
>
> http://www.svgopen.org/abstracts/lewis_et_al__bioviz_genome_viewer.html
>
> Here's another:
>
> http://www.labbook.com/
>
> Here's a third (ruby):
>
> http://gb.bioruby.org/
>
> There's also a commercial java based browser that uses XML as its data
> transport and SVG for its UI, but for the life of me I can't find the
> name or
> URL (it's in development).
>
> Lincoln
>
> On Monday 12 August 2002 03:12 pm, Bill Gooding wrote:
>> Hi,
>>
>> Although I am new to the mailing list, I have been looking at
>> bioinformatics information for a while and had a simple question. From
>> what I have seen it appears that in order to access the XML information
>> from various servers people use a downloaded java program which
>> implements
>> a GUI (Swing/AWT) for displaying information. I was wondering if
>> anyone
>> had considered using an XML based server that tranforms the data into
>> SVG
>> for display on a browser. That is, something similar to Cocoon. That
>> way,
>> differing XML format could be handled in a more comprehensive way. I
>> have
>> begun writing code to implement this idea (although it is not Cocoon
>> based
>> - I use jave xml api's) and am perfectly willing to donate it to
>> biodas.org
>> as open source as a start to developing such a system.
>>
>> So with that background my question is:
>>
>> 1. If a system such as I have proposed has been developed, where is
>> it ?
>> I just need a specific link.
>>
>> 2. If such a system does not exist, is anyone interested in the idea
>> or
>> want to discuss it ?
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Bill Gooding
>>
>>
>>
>> ---------------------------------
>> Do You Yahoo!?
>> HotJobs, a Yahoo! service - Search Thousands of New Jobs
> _______________________________________________
> DAS mailing list
> DAS@biodas.org
> http://biodas.org/mailman/listinfo/das
>
--
David Block dblock@gnf.org
GNF - San Diego, CA http://www.gnf.org
Genome Informatics / Enterprise Programming
Weblog: http://radio.weblogs.com/0104507/
_______________________________________________
DAS mailing list
DAS@biodas.org
http://biodas.org/mailman/listinfo/das
_______________________________________________
DAS mailing list
DAS@biodas.org
http://biodas.org/mailman/listinfo/das
---------------------------------
Do You Yahoo!?
HotJobs, a Yahoo! service - Search Thousands of New Jobs
--0-2142578151-1029786154=:41466
Content-Type: text/html; charset=us-ascii
<P>To everyone replying to my message,
<P>Thanks for your help, this is the sort of discussion that I wanted to start. On the specific comments:
<P>I am perfectly willing to work with Chris on the development of this software. The one thing I would like to insist on is that it be open source. I am sure that this probably goes without saying in this group :-). We really just need a place to put the project and people can download it if they like. As I said, I have developed a system which is based on JSP/Sevlets/Java. I think it is a good starting point. I am sure you would be surprised if I didn't think that :-).
<P>As for David Kulp's comments, I recognize that the system load may be a problem. But this problem to me would seem to plague any such system. That is, if you are looking at a whole chomosome down to the base pair level, you will have alot of data. I think that this can be addressed by limiting the size of the queries in the server which shouldn't be too hard. Also, the system I have developed, although it is JSP based, it will be very easy to create a standalone program for it so you don't have to go through a JSP server if you want to download and transform alot of data. The standalone program will use the same codebase as the JSP server (which will also allow easy test scripts to be written for the code) This should somewhat mitigate somewhat the load problem.
<P>On your comments about SVG/client integration/Adobe plugins, I really don't want to deal with this issue in the software (if I can avoid it). It seems like it may be problematic to support the plugin and all the browsers that may implement it slightly differently. For now, I think that the user can live with reloading data he needs. I understand this will increase server load. But my vision for this project is not to necessarily create something that would support an extremely high load (at least not at the beginning). I really intend this to be used within a relatively small group of users to simplify the access to data. So in my system, I really want to emphasize customizability. That is, if someone wants to display his data differently he should be able to plugin his XSLT files into the system very easily. I think what I have satisfies that. The advantage of open source would be that people could (hopefully) donate their own XSLT files to the project. This allows for many different views or processing of the data thus giving the users of the software more flexibility. At this point I would see the issue as a tradeoff between speed and flexibility. Maybe in later development any speed problems could be solved or strongly mitigated.
<P>As always, comments on this are welcome.
<P>Thanks,
<P>
<P>Bill Gooding
<P>
<P> <B><I>"Kulp, David" <DAVID_KULP@AFFYMETRIX.COM></I></B>wrote:
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">From the whizbang angle, I've been thinking about a DAS-SVG viewer. The<BR>"problem" is typical for genome browser displays: too many features<BR>significantly slows down display, both in terms of data transmission and SVG<BR>client rendering. I looked a little into how one might deal with dynamic<BR>content and semantic zooming. It turns out that the Adobe viewer provides<BR>two non-standard hooks which allow you to make URL calls and to parse the<BR>returning document into a DOM. Thus, javascript callbacks could be attached<BR>to zoom levels, hidden tracks, or objects, which caused the server to be<BR>queried for additional SVG which was then attached to the existing DOM.<BR>Sounds very cool!<BR><BR>But another problem is that SVG (at least with Adobe's viewer) has a<BR>hard-limit of 8 levels of zoom, i.e. a 256X zoom, but unless you're fancy,<BR>it's really just 4 levels of zoom in and 4 out. That's not enough to go<BR>from nucleotide to chromosome.<BR><BR>-d<BR><BR>-----Original Message-----<BR>From: David Block [mailto:dblock@gnf.org]<BR>Sent: Monday, August 19, 2002 10:33 AM<BR>To: Chris Lewis<BR>Cc: Bill Gooding; das@biodas.org; Lincoln Stein<BR>Subject: Re: [DAS] Question about das development.<BR><BR><BR>So close - the author of the first link was at BOSC!<BR><BR>Chris - this Bill Gooding wants to collaborate on an SVG viewer starting <BR>from XML and using XSLT - you guys should be collaborating.<BR><BR>Go for it!<BR>Dave<BR><BR>On Tuesday, August 13, 2002, at 05:51 AM, Lincoln Stein wrote:<BR><BR>> Search for "SVG" and "genome browser" on google. Here's one:<BR>><BR>> http://www.svgopen.org/abstracts/lewis_et_al__bioviz_genome_viewer.html<BR>><BR>> Here's another:<BR>><BR>> http://www.labbook.com/<BR>><BR>> Here's a third (ruby):<BR>><BR>> http://gb.bioruby.org/<BR>><BR>> There's also a commercial java based browser that uses XML as its data<BR>> transport and SVG for its UI, but for the life of me I can't find the <BR>> name or<BR>> URL (it's in development).<BR>><BR>> Lincoln<BR>><BR>> On Monday 12 August 2002 03:12 pm, Bill Gooding wrote:<BR>>> Hi,<BR>>><BR>>> Although I am new to the mailing list, I have been looking at<BR>>> bioinformatics information for a while and had a simple question. From<BR>>> what I have seen it appears that in order to access the XML information<BR>>> from various servers people use a downloaded java program which <BR>>> implements<BR>>> a GUI (Swing/AWT) for displaying information. I was wondering if <BR>>> anyone<BR>>> had considered using an XML based server that tranforms the data into <BR>>> SVG<BR>>> for display on a browser. That is, something similar to Cocoon. That <BR>>> way,<BR>>> differing XML format could be handled in a more comprehensive way. I <BR>>> have<BR>>> begun writing code to implement this idea (although it is not Cocoon <BR>>> based<BR>>> - I use jave xml api's) and am perfectly willing to donate it to <BR>>> biodas.org<BR>>> as open source as a start to developing such a system.<BR>>><BR>>> So with that background my question is:<BR>>><BR>>> 1. If a system such as I have proposed has been developed, where is <BR>>> it ?<BR>>> I just need a specific link.<BR>>><BR>>> 2. If such a system does not exist, is anyone interested in the idea <BR>>> or<BR>>> want to discuss it ?<BR>>><BR>>><BR>>><BR>>> Thanks,<BR>>><BR>>><BR>>><BR>>> Bill Gooding<BR>>><BR>>><BR>>><BR>>> ---------------------------------<BR>>> Do You Yahoo!?<BR>>> HotJobs, a Yahoo! service - Search Thousands of New Jobs<BR>> _______________________________________________<BR>> DAS mailing list<BR>> DAS@biodas.org<BR>> http://biodas.org/mailman/listinfo/das<BR>><BR>--<BR>David Block dblock@gnf.org<BR>GNF - San Diego, CA http://www.gnf.org<BR>Genome Informatics / Enterprise Programming<BR>Weblog: http://radio.weblogs.com/0104507/<BR><BR>_______________________________________________<BR>DAS mailing list<BR>DAS@biodas.org<BR>http://biodas.org/mailman/listinfo/das<BR>_______________________________________________<BR>DAS mailing list<BR>DAS@biodas.org<BR>http://biodas.org/mailman/listinfo/das</BLOCKQUOTE><p><br><hr size=1><b>Do You Yahoo!?</b><br>
<a href="http://rd.yahoo.com/careers/mailsig/new/*http://www.hotjobs.com">HotJobs, a Yahoo! service</a> - Search Thousands of New Jobs
--0-2142578151-1029786154=:41466--