Menu
▾
▴
gmod-ajax
|
From: Andrew U. <and...@gm...> - 2007-04-23 14:50:37
|
Hi everyone... Mitch and I presented a poster on AJAX GBrowse yesterday at RECOMB, and it was well received. Y'all can see the poster itself here: http://biowiki.org/twiki/pub/GBrowse/SkinnerUzilovMungallHolmesRecomb2007Poster/RECOMB2007posterSkinnerUzilovMungallSteinHolmes.pdf I just wanted to get some poster session impressions out of my head before I forget them... this is by no means a complete summary of what was mentioned... Mitch, you should add anything I'm missing: - We had a laptop set up running the demo... original GBrowse and AJAX GBrowse side-to-side to demonstrate. This was a good idea. - This is not the first time someone is making an AJAX or JavaScript genome browser, but ours is further along and more reusable than the other attempts. As a matter of fact, there seems to be a tendency for people to homebrew their own browsers for specific purposes in less-than-reusable fashion. A certain Bay Area company (should I mention who? I don't know what the etiquette rules are...) actually went as far as to reverse engineer the obfuscated JavaScript of Google Maps to make a spiffy custom browser (they never heard of the "Pragmatic Ajax" book)... then they invited us to demo our version for them sometime. I think I convinced some people to at least use GBrowse instead of homebrewing their own throwaway implementation. - A lot of people asked "can I do this or that track" or "this or that species"... it appears people have an impression that genome browsers are very restricted to the underlying data; they're used to them being purpose-specific. I tried to dispell this notion. - I also got some questions about file formats and database schemas. In general, it seems that it wasn't obvious that this is a generic browser useful for ANY feature data. - I got quite a few questions about why we're not using Java applets or SVG or Flash... one guy was particularly adamant in favor of Java applets (a few people seemed to think they were a bad idea), but I realized I can't really come up with a convincing reason AGAINST Java. SVG implementation is currently shaky, something which people at the session mentioned, and we simply don't know Flash, but that can be learned if there's a good reason for it. But why not Java applets? The only two reasons we came up with are (1) long load time, and (2) need to install Java, but that's not hard... - I got a couple of questions about whether our approach will scale. One gentleman did point out that storage requirements for e.g. a human genome would be ridiculous, even if we get rid of storing feature info in HTML. Related to this, I got many questions/suggestions that we should shift layout/rendering to the client side completely. There were quite a few people in favor of that idea and seem to think even JavaScript can do what we need. Anyway... there's other stuff I'm forgetting, but this is it for now. Andrew |
|
From: Ian H. <ih...@be...> - 2007-04-23 20:29:01
|
Hi Andrew, thanks for passing on all this feedback.
> less-than-reusable fashion. A certain Bay Area company (should I
> mention who? I don't know what the etiquette rules are...)
Unless they asked you not to mention them (which would be odd at an open
poster session), I don't see why not.
> "Pragmatic Ajax" book)... then they invited us to demo our version for
> them sometime.
Can you pass on contact details and I'll try to arrange a date?
> learned if there's a good reason for it. But why not Java applets?
> The only two reasons we came up with are (1) long load time, and (2)
> need to install Java, but that's not hard...
Interesting. I'd like to know what others think of this.
My answer to this question would be "of course we will welcome your Java
code contributions", delivered with a polite grin.
In all seriousness, I think we already have an emerging dream of a
language-agnostic message bus, certainly on the the server side.
I've been asked about standalone clients before. Google Earth often
comes up in these discussions. Sticking with the analogy, I usually
point out that (A) Google Maps came first and (B) the two applications
are designed to be compatible, but they occupy distinct niches in the
ecosystem.
One can argue language merits endlessly. Java has clear advantages.
Still, there ARE good reasons for scripting the web browser, rather than
budding off an applet, mainly to do with the interface. "Long load time"
and "no plugin" are part of it, but there are a whole lot of subtle
issues that go along with this: look & feel, web-browser integration,
compatibility with other components.
When language discussions go negative it's all over, but having said
that, if you DO get backed up against a wall and need a good reason
AGAINST Java, go and take a look at some of the Java genome browsers out
there. They just don't feel as light on their feet. I'm sure their
codebase is more stable, but they're not as fun.
I definitely DON'T want to block Java-heads from hitching a ride on our
message bus, so we probably need to avoid using JSON or other
Javascript-only tricks, and keep casual eye on compatibility. But I
don't want to switch to Java ;)
> - I got a couple of questions about whether our approach will scale.
> One gentleman did point out that storage requirements for e.g. a human
> genome would be ridiculous, even if we get rid of storing feature info
> in HTML.
So we definitely need HARD FACTS AND FIGURES at our disposal.
Anticipating such questions is due diligence we should be doing.
Do we have an actual estimate for human track size (fully-rendered)? A
gigabyte?
Even before having done the back-of-envelope calculation, I am going to
(perhaps unwisely) stick my neck out: I don't think the human genome
requirements are ridiculous when you stop to think about what you
actually have to achieve.
Specifically, I think the problem mostly melts away with a few simple
tricks, e.g.:
(1) Most tiles are whitespace, and you only really need to store one
image of an empty tile; all the other empty tiles can be symlinks back
to this one (this was/is the idea behind my MD5-filename hack for tile
images)
(2) Most close-up tiles won't ever get viewed, so rendering on demand
saves a lot of space;
(3) If the annotation upload facility takes off, you might not need more
than a few human genome installations at first, and the large
storage/cluster costs become centralized and benefit from economy of
scale (c.f. UCSC);
(4) Client-side rendering has to show up in this list of tricks; but, to
me, reimplementing parts of GBrowse in javascript is just another rabbit
we can pull out of the hat to address problems of scale, not a goal in
itself.
(5) Maybe we can even dip in and out of classic (CGI) GBrowse when we
need to, though Mitch has pointed out that this might complicate the
user experience somewhat.
> Related to this, I got many questions/suggestions that we
> should shift layout/rendering to the client side completely. There
> were quite a few people in favor of that idea and seem to think even
> JavaScript can do what we need.
I am gradually being persuaded that this is practical. Mitch has been
trying to get me on board his boatload of divs for some time now. I
realize it makes mashups easier too.
I still see it as just one thing in our bag of tricks for providing a
smooth experience, rather than an end in itself ("wow! porting code is
so much fun! why don't you rewrite the entire thing in F# and run it on
the Mono VM! Go on, I'll watch" </snark>)
Mitch has done quite well nudging forward Javascript rendering on the
sly. I'll probably get very excited about it as soon as it's
demonstrably the quickest route to a significant milestone, such as a
functioning prototype of a human genome wiki.
Our methodology so far has been to develop fluid, functional prototypes.
I hope we can keep doing that, and that this will lead us to the human
genome by small steps, each yielding an intermediate product of
practical interest.
Short answer: "Yes, clientside rendering offers many benefits and is
likely to help with scaling issues, like storage & rendering time. It is
definitely on our list."
> A lot of people asked "can I do this or that track" or "this or that
> species"... it appears people have an impression that genome browsers
> are very restricted to the underlying data
I think this really makes it worth emphasizing the "wiki farm" idea --
that anyone will eventually be able to create their own new species via
the web interface, a la Blogger or Wordpress.
To a Unix geek who can checkout & build GBrowse, that's an almost
trivial piece of functionality to expose via the web interface, but
clearly there are a lot of people who would benefit from it.
I.
|
|
From: Seth C. <sjc...@lb...> - 2007-04-24 01:14:59
|
On Mon, 2007-04-23 at 13:28 -0700, Ian Holmes wrote: > > learned if there's a good reason for it. But why not Java applets? > > The only two reasons we came up with are (1) long load time, and (2) > > need to install Java, but that's not hard... > > Interesting. I'd like to know what others think of this. I can think of a few! I've done stuff before with Java applets as web 2.0 type thingys, and my recollection is that it was very nasty. One still vivid nasty part is that there was no good way to have the Java applet and JavaScript communicate with each other, thereby trapping what you're doing on one side or the other. There were classes and objects to get around this, but the implementations were buggy and platform dependent (LiveConnect, etc.). Another big ding against applets was presentation/layout issues. For example, font resizing and layout won't work with the rest of the browser, making styles very hard to use and control. Also, printing just gave me some truncation and looked pretty bad when I tried it with an applet from Sun's Java site (the spreadsheet applet) and cut-and-paste didn't work at all. Scraping data would also be impossible. It's hard to just stick with the tangibles: things were very...fiddly. It may have all changed since I last did this years ago, but doing a cursory google search right now it looks to be in more or less the same state as I remember. It's hard to have the browser as a platform when it's actually Java. -Seth > My answer to this question would be "of course we will welcome your Java > code contributions", delivered with a polite grin. > > In all seriousness, I think we already have an emerging dream of a > language-agnostic message bus, certainly on the the server side. > > I've been asked about standalone clients before. Google Earth often > comes up in these discussions. Sticking with the analogy, I usually > point out that (A) Google Maps came first and (B) the two applications > are designed to be compatible, but they occupy distinct niches in the > ecosystem. > > One can argue language merits endlessly. Java has clear advantages. > > Still, there ARE good reasons for scripting the web browser, rather than > budding off an applet, mainly to do with the interface. "Long load time" > and "no plugin" are part of it, but there are a whole lot of subtle > issues that go along with this: look & feel, web-browser integration, > compatibility with other components. > > When language discussions go negative it's all over, but having said > that, if you DO get backed up against a wall and need a good reason > AGAINST Java, go and take a look at some of the Java genome browsers out > there. They just don't feel as light on their feet. I'm sure their > codebase is more stable, but they're not as fun. > > I definitely DON'T want to block Java-heads from hitching a ride on our > message bus, so we probably need to avoid using JSON or other > Javascript-only tricks, and keep casual eye on compatibility. But I > don't want to switch to Java ;) > > Related to this, I got many questions/suggestions that we > > should shift layout/rendering to the client side completely. There > > were quite a few people in favor of that idea and seem to think even > > JavaScript can do what we need. > > I am gradually being persuaded that this is practical. Mitch has been > trying to get me on board his boatload of divs for some time now. I > realize it makes mashups easier too. I think this is part of the |
|
From: Steve T. <st...@mo...> - 2007-04-24 13:53:21
|
Hi, > On Mon, 2007-04-23 at 13:28 -0700, Ian Holmes wrote: > >>>learned if there's a good reason for it. But why not Java applets? >>>The only two reasons we came up with are (1) long load time, and (2) >>>need to install Java, but that's not hard... >> >>Interesting. I'd like to know what others think of this. > > > I can think of a few! > > I've done stuff before with Java applets as web 2.0 type thingys, and my > recollection is that it was very nasty. One still vivid nasty part is > that there was no good way to have the Java applet and JavaScript > communicate with each other, thereby trapping what you're doing on one > side or the other. There were classes and objects to get around this, > but the implementations were buggy and platform dependent (LiveConnect, > etc.). > > Another big ding against applets was presentation/layout issues. For > example, font resizing and layout won't work with the rest of the > browser, making styles very hard to use and control. Also, printing just > gave me some truncation and looked pretty bad when I tried it with an > applet from Sun's Java site (the spreadsheet applet) and cut-and-paste > didn't work at all. Scraping data would also be impossible. > > It's hard to just stick with the tangibles: things were very...fiddly. > It may have all changed since I last did this years ago, but doing a > cursory google search right now it looks to be in more or less the same > state as I remember. > > It's hard to have the browser as a platform when it's actually Java. > Haven't posted for a while, but I just thought I would say well done to getting AJAX GBrowse this far. It just gets better and better! I absolutely agree with all these comments. I hate the language wars that seem to accompany certain discussions in bioinformatics. At the end of the day, users want functionality and I have seen far too many projects go down the 'we must rewrite it in Java' route to know that gains can be slight/non-existent for a massive amount of recoding. Applets are often slow to load and run (let's not forget some biologists still have older machines out there). There are some good small applets out there but developers who can program fast and nice looking applets I would say are few and far between. The fact is you can get considerable bang for your buck with the latest web technologies - providing a great user experience and allowing developers to code in what they want to at the back end. Keep up the good work - in the language of your choice! Steve ------------------------------------------------------------------ Medical Sciences Division Weatherall Institute of Molecular Medicine/Sir William Dunn School Oxford University |
|
From: Andrew U. <and...@gm...> - 2007-04-24 01:50:07
|
> > less-than-reusable fashion. A certain Bay Area company (should I > > mention who? I don't know what the etiquette rules are...) > > Unless they asked you not to mention them (which would be odd at an open > poster session), I don't see why not. > > > "Pragmatic Ajax" book)... then they invited us to demo our version for > > them sometime. > > Can you pass on contact details and I'll try to arrange a date? The company is Genentech. They've been brewing a lot of in-house stuff apparently. Andrew |
|
From: Andrew U. <and...@gm...> - 2007-04-24 01:52:30
|
On 4/23/07, Andrew Uzilov <and...@gm...> wrote: > > > less-than-reusable fashion. A certain Bay Area company (should I > > > mention who? I don't know what the etiquette rules are...) > > > > Unless they asked you not to mention them (which would be odd at an open > > poster session), I don't see why not. > > > > > "Pragmatic Ajax" book)... then they invited us to demo our version for > > > them sometime. > > > > Can you pass on contact details and I'll try to arrange a date? > > The company is Genentech. They've been brewing a lot of in-house > stuff apparently. Oh yeah... the man is Thomas Wu (tw...@ge...)... he seemed pretty excited about the browser. |
|
From: Hilmar L. <hl...@gm...> - 2007-04-25 20:49:07
|
On Apr 23, 2007, at 10:50 AM, Andrew Uzilov wrote: > I realized I can't really come up with a convincing reason AGAINST > Java. In my experience the main issues with applets are load-time and browser-specific event handling quirks that at first seem minor but turn out to be major headaches if one of the main goals is UI interactivity (which it seems to be here ...) I agree with the stylesheet disconnect issue raised - that's clearly undesirable. As for the some of the other arguments, such as printing or speed, in my experience they apply as much to JS or other embedded scripting languages for that matter (just compare a Google Map on the screen and once you print it, for example; you have full control over printing from an applet with a custom-written print handler). An old machine that slows down an applet will have at least as much issue with executing the JS. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X