[Biocorba-l] Biocorba-0.2.0 - A proposal
Brad Chapman
chapmanb@arches.uga.edu
Wed, 8 Nov 2000 17:57:06 -0500 (EST)
Hi Alan!
> Please find attached to this e-mail, a proposal for a next version of
> BioCorba that I hope answers some of the limitations of the current
> version.
This is very awesome! Thanks for putting this together. In general, I
really like the new version and will get some time together to update
biopython-corba to support this new version. I'm really happy we are
moving forward on things and will have a nice database to play with.
My small comments/concerns are below:
> This IDL will
> work with ORBacus & JavaORB for Java, ORBit for perl.
*sigh* no mention of python anywhere. How sad for us poor python
people. If you want to add it, this will work with omniORB, Fnorb and
ILU for python (although I probably won't mess with ILU unless someone
specifically asks me to).
> 5) Seq and SeqFeature now have the concept of sub-SeqFeatures. Thus
> the methods to return the SeqFeature objects of a Seq may specify
> whether all the SeqFeatures are to be returned, or just the top
> ones.
In general, this sounds cool. One thing, all of the functions that get
features in Seq have a sub_seqfeatures boolean which allows you to
choose between getting sub_seqfeatures and not getting them:
SeqFeatureVector all_SeqFeatures(in boolean sub_seqfeatures);
What would people think about getting rid of this boolean and always
returning all Sub-SeqFeatures? At least for me, this is the behavior I
believe I would want.
> 6) All version information (e.g. for PrimarySeq and PrimarySeqDB) is
> defined as a 'long' data type, rather than a 'string' data
> type. This decision was made on the basis that using a 'string'
> to specify the version makes it much less convenient to determine
> the most recent version of a database.
Really? It doesn't seem so hard to me:
$ python
Python 2.0 (#1, Oct 29 2000, 12:17:39)
[GCC 2.95.2 19991024 (release/franzo)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> '0.2' > '0.1'
1
>>> '0.1' < '0.0'
0
>>> '2.0' == '2.0'
1
Oh, maybe everyone else isn't using such a nice language to program in
:-).
Seriously, I am really for using strings over longs, even though it is
less convenient, just because I don't think it makes much sense to
version local databases with version numbers like 0.1. I would like to
version them with dates like '2000-01-03'. At least with python, I can
order these just as easily as version numbers, plus it actually makes
some sense when I'm trying to go back later and figure out what file
databases need updating or when a file database is from.
This is just my two cents though...
One other point I would like to bring up:
7) Can we move the memory counting stuff to an interface inside of
org.biocorba.seqcore? I think it is good to acknowledge that we got
things from Gnome work, but it also makes more sense to me to have
everthing inside the same interface, and then just have a little
acknowledgement to the Gnome folks. I would also like to drop the
query_interface() function, since we don't use it for anything. What
do people think about this?
Thanks again for everyone's work on this. Reading through the great
work you all did on these objects has really been a great learning
experience for me, and I'm looking forward to implementing it!
Brad