Mario Gianota wrote: > > The moment, the _very_ moment that bio-Java gets an IDE and an accompanying > web page with some reassuring screenshots is pretty much when you'll see the > user base expand to extremely healthy numbers. Until that day, bio-Java is > for expert Java programmers only --which is a shame really, isn't it? > > > --Mario Gianota
I like that prophecy. The issue realy is over what visual paradigm to chose, and which group of people have the time to glue it all together. Things like javascript, python and beanshell can all be used as scripting languages embedded within java apps. Some of the biojava classes fit nicely into the traditional beans framework (did I just say traditional about a java programming model?). Some of it does not, and it would be inapropreate to shoehorn it in there - e.g. the symbol tokenizers would suck for performance if they were beans. It's actualy quite easy to come up with a control-flow language that would allow users to draw directional pipes connecting files to processors to agregators to visualisation tools to output files etc. etc. ad nausium and do sensible optimizations over this framework, but who has the time to write the gui & glue code? The changeability framework gives us a huge tool for visualising data rippling through a network of data sources and processors, and I'm sure that these could be projected into a javabean world with a little tweaking (not sure we even need too many adapter classes). But it would be even better if the visual tools could work with our properties and events natively. In your view, which APIs or functionality should be visualy active so that joe-blogs can start clicking biojava apps together? What are your simple use cases? Any idea how it should look visualy? Matthew _______________________________________________ Biojava-l mailing list - [EMAIL PROTECTED] http://biojava.org/mailman/listinfo/biojava-l
