acedb future?

Ed Griffiths edgrif at
Wed Sep 6 09:30:55 EST 2000

> 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.

I can see what you are getting at but we will need to import a couple more good
programmers to do this, we have our hands full with supporting/extending acedb 
as it is. I also don't think that this will be at all straight forward, much of
the power of fmap comes from the combination of the sequence model(s) and the
fmap code combined. I don't know enough about sequence representation in other
databases to say if it would work to simply shove a different database on the
back of fmap....

> 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.

Why ??  Unix shares executable images between processes....

Shared libraries are OK but they can cause a lot of grief for users who just
want to pick up an executable and use it......this is why we have avoided them
so far.

> I agree with this, too.  The current ACeDB build system is, erm, shall
> we say idiosyncratic?  :-)

I think the build system is fine for developers but not good for users,
certainly neither Simon or I would argue against the introduction of autoconf.

> 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.

ok, this is the problem exactly.....

A "component" fmap sounds like a great idea but the devil is in the detail, how
many databases support the kind of information that acedb does ?? I don't know
the answer, I'm just saying that all this effort would only be worthwhile if
there really were other databases that could be efficiently queried to retrieve
this information.

cheers Ed

| Ed Griffiths, Acedb development, Informatics Group,                    |
|               The Sanger Centre, Wellcome Trust Genome Campus,         |
|               Hinxton, Cambridge CB10 1SA, UK                          |
|                                                                        |
| email: edgrif at   URL: |
|   Tel: +44-1223-494780       Fax: +44 1223 494919                      |

More information about the Acedb mailing list