[BioRuby] Codeml parser

[Pjotr Prins]

On Fri, Jan 08, 2010 at 04:29:07PM +0000, Jan Aerts wrote:
> Maybe it'd be a good idea to start thinking at a level removed from actual
> code, and create some general design documents first. Maybe we should
> * describe what we actually want to achieve with the bioruby toolkit: should
> it be a library foremost, or should it rather be an interface to run other
> programs (e.g. BLAST)?

I think calling into other programs is a good feature, but should be
really split out. Likewise for web services. Both split in terms of
objects and directory layout. Currently there is too intertwined
functionality.

Then there is support for reading and writing standard formats.

Then there is extra functionality (not found elsewhere, perhaps).

And we have Rails support and the shell.

All these should be clearly split out.

I don't think we have to choose. We can have it all. Just make sure
it sits in the right location.

> * make a high-level overview of different parts of bioruby:
>   - how do we handle file formats: are the files actual objects, or do they
> merely describe a biological entity? E.g. does a FASTA file merit the
> instantiation of a FASTA object, or is it nothing more than a container of
> Sequence objects?
>   - how do different parts of the library interact? Should we have a Root
> class such as in bioperl? What type of class should be used to interface
> with the world (e.g. file parsing)? What type of class should be used to
> actually contain the object data (e.g. annotated sequence)?
> 
> When that's done: come up with general guidelines for coding, e.g. always
> use keyword-based argument lists or something (just an example).

These choices are design choices and have to originate in a list of
shared 'values'. Because if we don't agree on a value there will
always be arguments and disagreement. One value would be 'clear
documentation', but this may collide with 'clear source code'.
Similarly 'Easy to use code' and 'Concise code' may collide. Or
functional choices over OOP. We need to put those values together and
rank them in importance. Once the ranking is set we can make easy
choices in guidelines.

I am writing a type of Manifest. I'll present that in the coming
weeks, when I feel I am ready. It is meant for discussion in Japan,
and after.

Pj.