[Biojava-l] changed (improved) SequenceDB and stuff

[Jason Stajich]

On Thu, 29 Jun 2000, Gerald Loeffler wrote:

> hilmar.lapp@pharma.Novartis.com wrote:
> > 
> > > Though minor in nature, the addition of the getName() method to
> > > interface SequenceDB will result in all implementations (outside the
> > > BioJava distribution) of this interface to break in the sense that they
> > > will all have to add an implementation of the getName() method...
> > >
> ...
> >      To make a long story short, what I wanted to suggest is, why not have an
> >      interface NamedSequenceDB which inherits from SequenceDB, and everyone is
> >      fine to have his SequenceDB implementation be a named one. There are a lot
> >      of cases where you simply don't need a name, and the fact that it hasn't
> >      been there until now at least doesn't disprove this.
> 
> you're absolutely right - i thought about doing exactly this (even using
> the same interface name) but dismissed it because i guessed (wrongly, it
> seems) that directly implementing SequenceDB (as opposed to using one of
> the supplied concrete implementations of SequenceDB) would not be too
> common (although i'm doing this right now (-:).
> 
> Anyways, as much as i'd hate to see an incompatible change like this
> happen in (lets say) one of the java.* packages, i'm not sure whether we
> should be so strict about BioJava. Absolutely prohibiting incompatible
> changes in BioJava is probably a bit premature because it hinders what
> is still a bit of a work-in-progress (definitely no offence intended,
> Matthew!).

While you're thinking about SequenceDBs - I'm working on a methodology
from the bioperl end to manage a MutableSeqDB - I want to be able to add /
update/ delete sequences from a 'real' database.  This is going to require
a transactional db on the back end and/or careful code, but we a looking
to see if we can do it with the ensembl project's db first.  This
would ideally something that would make its way into the biocorba idl as
well as implemented in the bio* project's code.  More details to come as I
finalize the design proposal.
 
> A possible way to manage change to the BioJava API could be to introduce
> versioning and restrict incomptible changes to the (rare) increases in
> the major version number. The symbol/seq-part of BioJava could be
> designated 1.0 right now, and future incompatible changes (like the
> ambiguity change or this db-naming change) may only occur in one go when
  moving to 2.0....
> 
> 	cheers,
> 	gerald
> 
> > 
> >      What do you think?
> > 
> >           Hilmar
> 
> -- 
>    Gerald.Loeffler@vienna.at _________________ Software Architect
>    http://www.imp.univie.ac.at ____ http://www.daemonstration.com
>    OOA&D, Java, J2EE, JSP, Servlets, JavaBeans, ODBMS, RDBMS, XML
> _______________________________________________
> Biojava-l mailing list  -  Biojava-l@biojava.org
> http://biojava.org/mailman/listinfo/biojava-l
> 

Jason Stajich
Center for Human Genetics
Duke University Medical Center
jason@chg.mc.duke.edu
(919)684-1806 (office)
(919)684-2275 (fax)
http://wwwchg.mc.duke.edu/