[Bioperl-l] 1.01

Jason Stajich jason@cgt.mc.duke.edu
Fri, 10 May 2002 17:05:23 -0400 (EDT)

I think we're accumulated enough things to justify a 1.01 release in the
coming weeks.  I'd like to see if we can't find a way to migrate the
latest ExtUtils::MakeMaker functionality into the Makefile.PL so that we
can avoid the problems we've had.  I know, some of you are saying, I just
got 1.0 installed, but this release will simply be bug fixes with no new

In the future I'd like to assess what all the external dependancies are
and make sure all are necessary and whether or not we can't reduce any of
them (Lincoln's essentially reimplemented LWP so might be able to factor
that out).

There have also been some constructive criticism of the docs/tutorial
about a need for a more comprehensive overview of many of the modules.
This is something I'd like us to work towards in the future major releases
but it might take more hands on deck and people who maybe are less
experienced and can help describe all the things that they found
difficult.  So if you're a newbie, some of the best things you can do is
keep a log of what you had to learn to get the toolkit working for you and
then help us put that into a newbie document or weave it into the
tutorial.  I think some well fleshed out war stories might be good too at
some point.

Some projects on the table that one might hope would be part of 1.2:

* Migrate Bio::Tools::HMMER to Bio::SearchIO
* migrate the Bio::DB::NCBIHelper module and its descendents to
  the new eutils that *seems* to be the way of the future for NCBI
  scriptable access
* Design the interface based on the Bioperl/PISE to describe
  remote analysis queues and add those classes to the main trunk.  Use
  this interface for local execution as well as remote.
* GenBank/EMBL/SwissProt parser re-eval.  Do we look at Inline::C + flex?
  YAPP?  Parse::RecDecent?  Speed is definitely hurting on these as I've
  been doing some profiling.
* As for speed - re-evaluate _rearrage() method as it is always the top
  culprit in object creation when doing profiling.
* Graphics Independent layer - deploy and port existing objects to it.  To
  allow possible SVG,PS,PDF,PNG,GIF through same object layer. (maybe?)
* Propose some interfaces & objects for expression data
* flesh out the cluster interface with Unigene work that Andrew has
* Interface to Assembly data - BioSQL will probably support this soon?

Jason Stajich
Duke University
jason at cgt.mc.duke.edu