[Biojava-dev] Feature interface change

[Schreiber, Mark]

Should we face up to the dreaded number sequences from zero, between
coordinates, just leave the damn thing be coordinate issues for BJ2?

I actually don't mind the coordinate system as is but numbering from
zero or btween coords could be more elegant.

- Mark


> -----Original Message-----
> From: Thomas Down [mailto:td2@sanger.ac.uk] 
> Sent: Friday, 23 August 2002 10:03 a.m.
> To: Schreiber, Mark
> Cc: Keith James; Matthew Pocock; biojava-dev@biojava.org
> Subject: Re: [Biojava-dev] Feature interface change
> 
> 
> On Fri, Aug 23, 2002 at 08:58:21AM +1200, Schreiber, Mark wrote:
> > 
> > It would make biojava less sequence centric which imho 
> would be a good 
> > thing. You could represent almost any kind of biological data this 
> > way, mapping it to sequence if needed but also to experimental 
> > results, literature searches etc.
> > 
> > How much breakage would occur to the biojava api? It would 
> be good to 
> > have this sooner rather than latter.
> 
> I think doing this properly will mean some pretty serious 
> breakage.  There are actually a number of fairly big issues 
> that have been talked about in various context lately.  Off 
> the top of my head:
> 
>    - FeatureCards
>    - Consistent use of identifiers.
>    - Use of ontologies (I think this one relates quite stronly to
>      the FeatureCards).
>    - Revamping the ChangeEvent system to handle event forwarding
>      better (I've already been trying out a few ideas in this
>      direction in the latest version of the BioSQL code).
>    - Object query language (more powerful/flexible than the
>      FeatureFilter `language').
>    - Probably some others.  SeqIO changes?
> 
> Pretty much all of these imply at least some API breakage.  
> I'm tempted to route around this by forking into `evolution' 
> (1.x, try to remain completely API compatible with current 
> stuff) and revolution (2.0, lots of cool stuff, lots of API 
> breakage). Maybe even start with a completely fresh 
> repository for the 2.0 stuff.
> 
> When I suggest this, I'm thinking particularly about Tomcat's 
> fork into 3.x and 4.x branches (where 4.x was a complete 
> re-write). It caused some pain, but 4.x ended up a much nicer 
> package. 
> It certainly seems a better idea to me than trying to 
> implement major changes to the current codebase (and still 
> breaking everyone's code in practice...).
> 
> Anyway, I think this is all likely to be fairly long term 
> stuff... Any other thoughts?
> 
>      Thomas.
> 
=======================================================================
Attention: The information contained in this message and/or attachments
from AgResearch Limited is intended only for the persons or entities
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipients is prohibited by AgResearch
Limited. If you have received this message in error, please notify the
sender immediately.
=======================================================================