In article <Pine.LNX.4.10.10009040852150.12440-100000 at riker.ebi.ac.uk>,
Ewan Birney <birney at ebi.ac.uk> wrote:
>>(a) componentise heavily. ACeDB should become 4-5 separate projects,
>with their own release schedules and cvs modules, being something like:
>> (i) database kernel
In my view the current database kernel should be thrown out entirely (or
at least made just one possible kernel people can use), and the
remaining components below, thanks to the bioobject layer, made kernel
independent. That would allow people to bind the superb visualisation
features that ACeDB has to other databases.
> (ii) bioobject layer
>> (iii) graphics library
>> (iv) fmap
>> (v) other viewers
Sounds very sensible. I find the current architecture of ACeDB really
awkward - the massive code duplication between tace, giface and xace,
without even using shared libraries is really scary.
>The new projects, in my mind, would not be run via the classic ACeDB
>source code management system + makefile, but a more vanilla cvs with
>autoconf style configurations, lowering the problems of entry for new
>developers to work with you guys.
I agree with this, too. The current ACeDB build system is, erm, shall
we say idiosyncratic? :-)
> - make fmap the world's best, fast, large genome viewer. Look at the
>apollo server IDL and leverage that. Discuss what people like and hate
>about fmap. Integrate GAZE and other 3rd party programs using everything
>from a stanardised GFF system call-out to CORBA based services.
I'm certainly keen on this idea; fmap is still the best genome
annotation display I have seen, if only because it display vertically.
I don't know why no other annotation viewer authors have cottoned onto
this idea; it allows you to view a sequence on a large scale, and still
be able to read labels on the annotation, something that becomes
impossible as soon as you display sequences horizontally, when you have
to make decisions about what labels you can and cannot show.
I suspect the principal barrier at the moment is that the various
components of ACeDB are not well separated, and that large chunks of the
fmap code are hard-wired, and will be difficult to separate from the
database. Not that this is impossible, of course, but I would imagine
it will be fairly painful.
Depending on how painful it is, it might be simpler to just take the
FMAP display as a good idea, and re-implement it from scratch on top of
your bioobjects layer.
The simplistic Java viewer that Matt showed us at the BOSC conference
was a good move in the right direction; like FMAP, it divided the
display up into rectangles (sadly they were rows rather than columns)
into which each type of annotation was responsible for drawing itself.
That kind of modular architecture is a real win, in my view.
I'd like to make the plea though that we should from the beginning not
look at this as purely a viewer, but think of it as a read-write
interface to the underlying data from the word go. Hand annotation is
one thing that most genomic viewers currently don't handle well,
with the exception of FMAP, Artemis and possibly others that I'm not
aware of.
Re-reading this message, it sounds like I'm attacking ACeDB. I'm not, I
still think it's the leader for hand annotation, but I agree with Ewan
that it really does need some major re-working to bind it to
up-and-coming database and annotation strategies; interoperability
between tools is the key!
Phew... rant over. :-)
Tim.
