[Biojava-l] Re: introducing a location-less feature into BioJava
Aaron Kitzmiller
AKitzmiller@genetics.com
Mon, 15 May 2000 13:39:50 -0400
Don't know if the location-less feature is still an issue or not, but...
It seems to me that the proper way to use BioJava Features is as an interface implemented by some other class. For example, a PredictedExon class, which might include detailed information about the tool used to do the prediction, could have a base class PredictedExonFeature that implemented the Feature interface. The comparison of two features could then be done outside of location when necessary.
The location-less feature alternatives that have been discussed either leave Feature as a wrapper for a name, or involve a 'type' field, which is almost always a no-no in OO :).
ajk
Aaron Kitzmiller
Manager Systems Development -Cambridge
Bioinformatics Department
35 Cambridge Park Dr.
Cambridge, MA 02140
Phone: (617) 665-6831
Fax: (617) 665-8870
Email: akitzmiller@genetics.com
>>> <biojava-l-admin@biojava.org> 05/10 12:00 PM >>>
Send Biojava-l mailing list submissions to
biojava-l@biojava.org
To subscribe or unsubscribe via the web, visit
http://biojava.org/mailman/listinfo/biojava-l
or, via email, send a message with subject or body 'help' to
biojava-l-request@biojava.org
You can reach the person managing the list at
biojava-l-admin@biojava.org
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Biojava-l digest..."
Today's Topics:
1. Source dist corrupted? (hilmar.lapp@pharma.novartis.com)
2. introducing a location-less feature into BioJava (Gerald Loeffler)
3. Re: introducing a location-less feature into BioJava (hilmar.lapp@pharma.novartis.com)
4. biojava intallation (Imre Vastrik)
5. Re: Source dist corrupted? (Matthew Pocock)
6. Re: Source dist corrupted? (Matthew Pocock)
7. Re: Bioperl: Re: Bio::CorbaServer Updated (Jason Stajich)
8. Re: Source dist corrupted? (hilmar.lapp@pharma.novartis.com)
9. Re: Re: introducing a location-less feature into BioJava (Matthew Pocock)
10. Re: Source dist corrupted? (Matthew Pocock)
11. Re: Re: Bioperl: Re: Bio::CorbaServer Updated (Matthew Pocock)
--__--__--
Message: 1
From: hilmar.lapp@pharma.Novartis.com
To: biojava-l@biojava.org
Date: Tue, 9 May 2000 21:20:39 +0100
Subject: [Biojava-l] Source dist corrupted?
Dear all,
maybe no-one of you is using the source distribution packaged as .tar.gz from
the download
area the web site points to, but that's what I did today (already the 2nd
attempt), and I failed to compile (build) the classes (I'm using a Java 1.2.2
port on Irix) because some files seem to be missing from the distribution:
[...]
src/org/biojava/bio/dp/FlatModel.java:39: Superclass
org.biojava.bio.dp.ModelView of class org.biojava.bio.dp.FlatModel not found.
public class FlatModel extends ModelView {
^
src/org/biojava/bio/dp/FlatModel.java:322: Superclass
org.biojava.bio.dp.StateView of nested class org.biojava.bio.dp.FlatModel.
EmissionWrapper not found.
extends StateView
^
src/org/biojava/bio/seq/tools/SimpleCrossProductAlphabet.java:40: Interface
org.biojava.bio.seq.tools.CrossProductAlphabet of class
org.biojava.bio.seq.tools.SimpleCrossProductAlphabet not found.
class SimpleCrossProductAlphabet implements FiniteAlphabet, CrossProductAlphabet
{
[... lots of further errors deleted]
The classes seem to present in the jar which is also provided for download. I'm
wondering
whether you expect people to either get the jar or fetch their own CVS tree. CVS
is not an
option for me because I can't get through our firewall.
Second, while I skimmed through the mail archive, I noticed that apparently you
recently
renamed some of the core classes (like ResidueList), and moved others. Maybe I
misunderstood
this, but if not, would it mean, that the current API will partially become
invalid in the very next distribution, or already is in the current CVS
controlled repository. That is, how
stable is the API, and if it is still unstable but at least parts have already
settled, how can one discriminate between these.
Cheers,
Hilmar
-----------------------------------------------------------------------------
Hilmar Lapp email: Hilmar.Lapp@pharma.novartis.com
NFI Vienna, IFD/Bioinformatics phone: +43 1 86634 631
A-1235 Vienna fax: +43 1 86634 727
ROI: Bioinformatics (arrays, expression, seqs), Programming (OO), Databases
-----------------------------------------------------------------------------
--__--__--
Message: 2
Date: Tue, 09 May 2000 22:02:30 +0200
From: Gerald Loeffler <Gerald.Loeffler@vienna.at>
Organization: Daemonstration Software Consulting
To: Biojava-l@biojava.org
CC: mike@wildpaner.com
Subject: [Biojava-l] introducing a location-less feature into BioJava
Hi!
i'd like to argue for the removal of the Location-property (method
getLocation()) from org.biojava.bio.seq.Feature, so that features are
location-less, and in turn for the introduction of a new type
(interface) org.biojava.bio.seq.LocatedFeature that has a
Location-property (method getLocation()) as well as a Feature-property
(method getFeature()).
Rationale:
Imagine that sequences A and B (which naturally are FeatureHolders) both
have a feature in common, say a SET-domain. Currently, i see no other
way to represent this in BioJava than to associate a distinct Feature
object with sequence A and another, distinct Feature object with
sequence B. The reason for this is that in order for a feature to be
useful i have to give its location with respect to the FeatureHolder
(the sequences) - and the location of the SET-domain in sequence A will
be different from that in sequence B. Apart from working with
Annotation-conventions on the features, i've no way of making explicit
the fact that these two features are really the same domain.
If, on the other hand, Feature would not contain a Location-property, i
could create a Feature object for the SET-domain (in general). A
distinct LocatedFeature object must then be constructed to link sequence
A to the SET-domain Feature, giving the location of the domain in
sequence A; and the same must be done for sequence B. But the so-created
distinct LocatedFeature objects would explicitly share (hold a reference
to) the same Feature object (for the SET-domain).
What do you think? Am i missing something?
cheers,
gerald
--
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
--__--__--
Message: 3
From: hilmar.lapp@pharma.Novartis.com
To: Biojava-l@biojava.org
Date: Wed, 10 May 2000 01:16:13 +0100
Subject: [Biojava-l] Re: introducing a location-less feature into BioJava
If, on the other hand, Feature would not contain a Location-property, i
could create a Feature object for the SET-domain (in general). A
distinct LocatedFeature object must then be constructed to link sequence
A to the SET-domain Feature, giving the location of the domain in
sequence A; and the same must be done for sequence B. But the so-created
distinct LocatedFeature objects would explicitly share (hold a reference
to) the same Feature object (for the SET-domain).
Right. While the present design is similar to bioperl, it is contrary to
how
I guess most people design a sequence database with features (n-n).
This makes it then possible to ask a database to return all sequences
having a specific feature, and where this feature is. So, similarly
you would like to be able to ask a specific Feature object for
returning all its assignments to FeatureHolders, instead of having
to iterate over all FeatureHolders and query each whether they contain
a Feature of a particular type.
The question is maybe whether or not FeatureHolders should own the
Features they hold, in the sense that the location of the Feature
refers to its holder. Or you look at Features as abstract types of
their own, in the sense that they can be 'attached' to an arbitrary
number of FeatureHolders, and each attachment has a location (and
maybe even more properties, like a score, and the attachment to
different strands does not necessarily make a different feature, so
the strand may also be an attachment property).
Hilmar
--__--__--
Message: 4
Date: Wed, 10 May 2000 11:01:30 +0300
From: Imre Vastrik <imre.vastrik@helsinki.fi>
Reply-To: imre.vastrik@helsinki.fi
To: biojava-l@biojava.org
Subject: [Biojava-l] biojava intallation
Dear all,
For a real java newby like me it would have saved a considerable amount
of time had there been somewhat more detailed README. The two extremely
useful truths that I happened to find out in the hard way were:
-run the buildall.sh script from biojava-live directory, i.e type:
./build/buildall.sh
-set the environmental variable CLASSPATH to
.:<path-to-biojava-live-dir>/xml.jar:<path-to-biojava-live-dir>/biojava.jar
then:
% cd demos/seq
% javac TestEmbl.java
% java TestEmbl AL121903.embl
AL121903 has 191 features
%
...and voila, the thing works! Maybe someone could include this in the
README to decrease the misery of people not fluent in java.
Rgds.,
imre
--------------------------------------------
- Imre Vastrik, Ph.D., tel:+359-9-19126886 -
- http://www.hi.helsinki.fi/bioinfo -
--------------------------------------------
--__--__--
Message: 5
Date: Wed, 10 May 2000 11:31:30 +0100
From: Matthew Pocock <mrp@sanger.ac.uk>
Organization: The Sanger Center
To: hilmar.lapp@pharma.Novartis.com
CC: biojava-l@biojava.org
Subject: Re: [Biojava-l] Source dist corrupted?
I am just about to post today's build to the FTP site, and also update the README. I
will post once this is done.
Matthew
hilmar.lapp@pharma.Novartis.com wrote:
> Dear all,
>
> maybe no-one of you is using the source distribution packaged as .tar.gz from
> the download
> area the web site points to, but that's what I did today (already the 2nd
> attempt), and I failed to compile (build) the classes (I'm using a Java 1.2.2
> port on Irix) because some files seem to be missing from the distribution:
>
> [...]
> src/org/biojava/bio/dp/FlatModel.java:39: Superclass
> org.biojava.bio.dp.ModelView of class org.biojava.bio.dp.FlatModel not found.
> public class FlatModel extends ModelView {
> ^
> src/org/biojava/bio/dp/FlatModel.java:322: Superclass
> org.biojava.bio.dp.StateView of nested class org.biojava.bio.dp.FlatModel.
> EmissionWrapper not found.
> extends StateView
> ^
> src/org/biojava/bio/seq/tools/SimpleCrossProductAlphabet.java:40: Interface
> org.biojava.bio.seq.tools.CrossProductAlphabet of class
> org.biojava.bio.seq.tools.SimpleCrossProductAlphabet not found.
> class SimpleCrossProductAlphabet implements FiniteAlphabet, CrossProductAlphabet
> {
> [... lots of further errors deleted]
>
> The classes seem to present in the jar which is also provided for download. I'm
> wondering
> whether you expect people to either get the jar or fetch their own CVS tree. CVS
> is not an
> option for me because I can't get through our firewall.
>
> Second, while I skimmed through the mail archive, I noticed that apparently you
> recently
> renamed some of the core classes (like ResidueList), and moved others. Maybe I
> misunderstood
> this, but if not, would it mean, that the current API will partially become
> invalid in the very next distribution, or already is in the current CVS
> controlled repository. That is, how
> stable is the API, and if it is still unstable but at least parts have already
> settled, how can one discriminate between these.
>
> Cheers,
>
> Hilmar
>
> -----------------------------------------------------------------------------
> Hilmar Lapp email: Hilmar.Lapp@pharma.novartis.com
> NFI Vienna, IFD/Bioinformatics phone: +43 1 86634 631
> A-1235 Vienna fax: +43 1 86634 727
> ROI: Bioinformatics (arrays, expression, seqs), Programming (OO), Databases
> -----------------------------------------------------------------------------
>
> _______________________________________________
> Biojava-l mailing list - Biojava-l@biojava.org
> http://biojava.org/mailman/listinfo/biojava-l
--__--__--
Message: 6
Date: Wed, 10 May 2000 11:56:28 +0100
From: Matthew Pocock <mrp@sanger.ac.uk>
Organization: The Sanger Center
To: hilmar.lapp@pharma.Novartis.com, biojava-l@biojava.org
Subject: Re: [Biojava-l] Source dist corrupted?
Matthew Pocock wrote:
> I am just about to post today's build to the FTP site, and also update the README. I
> will post once this is done.
>
> Matthew
>
Done! You can grab biojava.jar from the FTP site at:
ftp://biojava.org/pub/biojava/
or
ftp://bioperl.org/pub/biojava/
I can't make explorer 5 connect to the biojava ftp server, but netscape does (don't ask
me why). This distribution should work, but please tell me if you have any problems.
Matthew
>
> hilmar.lapp@pharma.Novartis.com wrote:
>
> > Dear all,
> >
> > maybe no-one of you is using the source distribution packaged as .tar.gz from
> > the download
> > area the web site points to, but that's what I did today (already the 2nd
> > attempt), and I failed to compile (build) the classes (I'm using a Java 1.2.2
> > port on Irix) because some files seem to be missing from the distribution:
> >
> > [...]
> > src/org/biojava/bio/dp/FlatModel.java:39: Superclass
> > org.biojava.bio.dp.ModelView of class org.biojava.bio.dp.FlatModel not found.
> > public class FlatModel extends ModelView {
> > ^
> > src/org/biojava/bio/dp/FlatModel.java:322: Superclass
> > org.biojava.bio.dp.StateView of nested class org.biojava.bio.dp.FlatModel.
> > EmissionWrapper not found.
> > extends StateView
> > ^
> > src/org/biojava/bio/seq/tools/SimpleCrossProductAlphabet.java:40: Interface
> > org.biojava.bio.seq.tools.CrossProductAlphabet of class
> > org.biojava.bio.seq.tools.SimpleCrossProductAlphabet not found.
> > class SimpleCrossProductAlphabet implements FiniteAlphabet, CrossProductAlphabet
> > {
> > [... lots of further errors deleted]
> >
> > The classes seem to present in the jar which is also provided for download. I'm
> > wondering
> > whether you expect people to either get the jar or fetch their own CVS tree. CVS
> > is not an
> > option for me because I can't get through our firewall.
> >
> > Second, while I skimmed through the mail archive, I noticed that apparently you
> > recently
> > renamed some of the core classes (like ResidueList), and moved others. Maybe I
> > misunderstood
> > this, but if not, would it mean, that the current API will partially become
> > invalid in the very next distribution, or already is in the current CVS
> > controlled repository. That is, how
> > stable is the API, and if it is still unstable but at least parts have already
> > settled, how can one discriminate between these.
> >
> > Cheers,
> >
> > Hilmar
> >
> > -----------------------------------------------------------------------------
> > Hilmar Lapp email: Hilmar.Lapp@pharma.novartis.com
> > NFI Vienna, IFD/Bioinformatics phone: +43 1 86634 631
> > A-1235 Vienna fax: +43 1 86634 727
> > ROI: Bioinformatics (arrays, expression, seqs), Programming (OO), Databases
> > -----------------------------------------------------------------------------
> >
> > _______________________________________________
> > Biojava-l mailing list - Biojava-l@biojava.org
> > http://biojava.org/mailman/listinfo/biojava-l
>
> _______________________________________________
> Biojava-l mailing list - Biojava-l@biojava.org
> http://biojava.org/mailman/listinfo/biojava-l
--__--__--
Message: 7
Date: Wed, 10 May 2000 09:42:22 -0400 (EDT)
From: Jason Stajich <jason@chg.mc.duke.edu>
To: Matthew Pocock <mrp@sanger.ac.uk>, Ewan Birney <birney@ebi.ac.uk>
cc: Bioperl <vsns-bcd-perl@lists.uni-bielefeld.de>,
BioJava List <biojava-l@biojava.org>
Subject: [Biojava-l] Re: Bioperl: Re: Bio::CorbaServer Updated
I tried java server + perl client, AND perl server + java client yes it
does work. I only used the SeqDB demo that was available in the
biojava demos. More tests to come later.
I will be trying out Brad Chapman's Biopython Corba client and server
today as well and see if everything can work together.
-Jason
On Wed, 10 May 2000, Matthew Pocock wrote:
> Do you know if the java server <-> perl client works? (or, for that matter, perl
> server <-> java client). Am I getting ahead of myself?
>
> Matthew
>
> Jason Stajich wrote:
>
> > Server code is ready to play for the most part. I am trying to track down
> > the bug that
> > causes the server to crash in Python - see Brad's previous message - seems
> > to come from the is_a call but I haven't determined what the workaround is.
> > But you can definitely create a SeqDB and serve up Seqs. Perl server <->
> > Perl client seems to be working fine for me.
> >
> > I am still working with the Bio::CorbaClient code but should be done with
> > the first iteration soon - probably this afternoon or tomorrow morning.
> >
> > I'd like to examine memory issues and the BioEnv in more detail as soon as I
> > get the Client code out.
> >
> > -Jason
> >
> > ----- Original Message -----
> > From: "Ewan Birney" <birney@ebi.ac.uk>
> > To: "Jason Stajich" <jason@chg.mc.duke.edu>
> > Cc: "Brad Chapman" <chapmanb@arches.uga.edu>; "Bioperl"
> > <vsns-bcd-perl@lists.uni-bielefeld.de>
> > Sent: Tuesday, May 09, 2000 6:30 PM
> > Subject: Re: Bioperl: Re: Bio::CorbaServer Updated
> >
> > >
> > >
> > > jason -
> > >
> > > can you give us an update of where the bioperl biocorba implementations
> > > are? Are we ready to play yet?
> > >
> > >
> > >
> > > -----------------------------------------------------------------
> > > Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
> > > <birney@ebi.ac.uk>.
> > > -----------------------------------------------------------------
> > >
> > > =========== Bioperl Project Mailing List Message Footer =======
> > > Project URL: http://bio.perl.org/
> > > For info about how to (un)subscribe, where messages are archived, etc:
> > > http://www.techfak.uni-bielefeld.de/bcd/Perl/Bio/vsns-bcd-perl.html
> > > ====================================================================
> > >
> >
> > =========== Bioperl Project Mailing List Message Footer =======
> > Project URL: http://bio.perl.org/
> > For info about how to (un)subscribe, where messages are archived, etc:
> > http://www.techfak.uni-bielefeld.de/bcd/Perl/Bio/vsns-bcd-perl.html
> > ====================================================================
>
>
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/
--__--__--
Message: 8
From: hilmar.lapp@pharma.Novartis.com
To: Matthew Pocock <mrp@sanger.ac.uk>
cc: biojava-l@biojava.org
Date: Wed, 10 May 2000 15:46:32 +0100
Subject: Re: [Biojava-l] Source dist corrupted?
Matthew Pocock wrote:
> I am just about to post today's build to the FTP site, and also update the
README. I
> will post once this is done.
>
> Matthew
>
Done! You can grab biojava.jar from the FTP site at:
ftp://biojava.org/pub/biojava/
or
ftp://bioperl.org/pub/biojava/
I can't make explorer 5 connect to the biojava ftp server, but netscape does
(don't ask
me why). This distribution should work, but please tell me if you have any
problems.
Matthew
Gerald was already kind enough to send me a CVS checkout, and after some
confusion about the best way of how to build it I finally succeeded using
the build/Build.java tool. I haven't tried any of the test programs yet,
though.
As you and no-one else hasn't commented yet on the second question I raised
in my mail, I'd like to raise it once again. Please don't get me wrong, I
didn't want to critizise.
Stability is simply one of the decisive criteria for me to decide whether I
can use something for coding applications that are likely to go productive
soon, or whether it is something to be evaluated for its potential utility
in the future.
We have Java 'productive' (in the sense that they are used for routine
bioinf) applications dealing with sequences, and I have to extend their
functionality. The question for me is whether this is an opportunity and
worth the effort to integrate already now a public classlib which may
become kind of a standard at some day.
Cheers,
Hilmar
--__--__--
Message: 9
Date: Wed, 10 May 2000 14:59:57 +0100
From: Matthew Pocock <mrp@sanger.ac.uk>
Organization: The Sanger Center
To: hilmar.lapp@pharma.Novartis.com
CC: Biojava-l@biojava.org
Subject: Re: [Biojava-l] Re: introducing a location-less feature into BioJava
Hi.
I think the issue is over the distinction between an individual feature, and the
type of the feature. In the example fo the SET-domain feature, each sequence has
a unique feature (in location, and possibly in the feature's sequence). However,
they both convey the same information - that that particular region is an example
of a SET-domain.
The loose-binding way to represent this is to 'agree' an annotation key
'domain.type' with the value being a reference to the SET-domain object. This is
the ideal solution if the code is for use by a small group, and if you want to
avoid writing any volume of code, or if you are scripting-language people (perl,
tcl, python etc.) and like to do things this way. It would also play nicely with
simple sequence browsers that know how to peek into the annotation bundle.
The tight-binding way would be to add a DomainType field to a new interface
DomainFeature, and have this reference the SET-domain object. This would be the
correct approach for representing a well-known resource like interpro where the
concepts of domain-type are constant and well understood :-D particularly if it
formed the basis of a library that you distributed.
A stupidly tight-binding way would be to have a SETDomainFeature (and another
feature class for each type of domain), but this will soon become unworkable, and
I think that the domain-type is best represented as multiple (possibly
polymorphic) instances of some DomainType interface that is associated with a
DomainFeature, or under the 'domain.type' annotation key.
Your database of domains may chose to keep a reference to the sequence/feature
that represents this particular SET-domain (allowing quick look-up of all
SET-domain features in existance), but this is your choice. If this is done
inside the same Java process (not via corba or SQL lookups) then you need to be
careful that sequences can be garbage-collected, but this is no great shakes
using the soft-references in 1.2.
So - a feature is specific to a sequence and its location (like an object is
specific to the memory it owns and the member-variable values it has), where as
the domain in this example is accessory information to the feature that gives the
feature type (like a class).
Would this fit into your world view, or have I missed the point somewhere?
Matthew
hilmar.lapp@pharma.Novartis.com wrote:
> If, on the other hand, Feature would not contain a Location-property, i
> could create a Feature object for the SET-domain (in general). A
> distinct LocatedFeature object must then be constructed to link sequence
> A to the SET-domain Feature, giving the location of the domain in
> sequence A; and the same must be done for sequence B. But the so-created
> distinct LocatedFeature objects would explicitly share (hold a reference
> to) the same Feature object (for the SET-domain).
>
> Right. While the present design is similar to bioperl, it is contrary to
> how
> I guess most people design a sequence database with features (n-n).
> This makes it then possible to ask a database to return all sequences
> having a specific feature, and where this feature is. So, similarly
> you would like to be able to ask a specific Feature object for
> returning all its assignments to FeatureHolders, instead of having
> to iterate over all FeatureHolders and query each whether they contain
> a Feature of a particular type.
>
> The question is maybe whether or not FeatureHolders should own the
> Features they hold, in the sense that the location of the Feature
> refers to its holder. Or you look at Features as abstract types of
> their own, in the sense that they can be 'attached' to an arbitrary
> number of FeatureHolders, and each attachment has a location (and
> maybe even more properties, like a score, and the attachment to
> different strands does not necessarily make a different feature, so
> the strand may also be an attachment property).
>
> Hilmar
>
> _______________________________________________
> Biojava-l mailing list - Biojava-l@biojava.org
> http://biojava.org/mailman/listinfo/biojava-l
--__--__--
Message: 10
Date: Wed, 10 May 2000 15:08:15 +0100
From: Matthew Pocock <mrp@sanger.ac.uk>
Organization: The Sanger Center
To: hilmar.lapp@pharma.Novartis.com
CC: biojava-l@biojava.org
Subject: Re: [Biojava-l] Source dist corrupted?
hilmar.lapp@pharma.Novartis.com wrote:
> Matthew Pocock wrote:
>
> Gerald was already kind enough to send me a CVS checkout, and after some
> confusion about the best way of how to build it I finally succeeded using
> the build/Build.java tool. I haven't tried any of the test programs yet,
> though.
>
The FTP site should contain biojava.jar which is a complete jar file of the .class
files. This should give you access to the running code. Also on the FTP site is
biojava-live.tar.gz which is a clean export of the project. This *should* be the
version that was used to build biojava.jar. Also, dated versions of these files are
on the site so that if you found that a particular build worked, you can always get
it again.
>
> As you and no-one else hasn't commented yet on the second question I raised
> in my mail, I'd like to raise it once again. Please don't get me wrong, I
> didn't want to critizise.
> Stability is simply one of the decisive criteria for me to decide whether I
> can use something for coding applications that are likely to go productive
> soon, or whether it is something to be evaluated for its potential utility
> in the future.
>
The object model for sequences (Sequence, Feature, Symbol etc.) are rock-solid.
There may be bugs in the implementations, but fixing these shouldn't change the API
in any way. The DP and corba packages are relatively stable APIs, but not set in
stone.
We should probably think about moving towards a release version that is a stable
mile-stone for people to evaluate BioJava from. Is there anything missing from the
current package that should be in that? Is there anything in the current package
that should be left out of a full release?
>
> We have Java 'productive' (in the sense that they are used for routine
> bioinf) applications dealing with sequences, and I have to extend their
> functionality. The question for me is whether this is an opportunity and
> worth the effort to integrate already now a public classlib which may
> become kind of a standard at some day.
>
> Cheers,
>
> Hilmar
>
> _______________________________________________
> Biojava-l mailing list - Biojava-l@biojava.org
> http://biojava.org/mailman/listinfo/biojava-l
--__--__--
Message: 11
Date: Wed, 10 May 2000 15:16:57 +0100
From: Matthew Pocock <mrp@sanger.ac.uk>
Organization: The Sanger Center
To: Jason Stajich <jason@chg.mc.duke.edu>
CC: Ewan Birney <birney@ebi.ac.uk>,
Bioperl <vsns-bcd-perl@lists.uni-bielefeld.de>,
BioJava List <biojava-l@biojava.org>
Subject: Re: [Biojava-l] Re: Bioperl: Re: Bio::CorbaServer Updated
Jason,
Jason Stajich wrote:
> I tried java server + perl client, AND perl server + java client yes it
> does work. I only used the SeqDB demo that was available in the
> biojava demos. More tests to come later.
>
This is VERY cool! The one area that I would concentrate your tests on is the memory
handeling - I am not entierly sure that I correctly implemented the GNOME
reference-counting stuff. But still - it is great to see CORBA interoperability
between these languages.
Matthew
>
> I will be trying out Brad Chapman's Biopython Corba client and server
> today as well and see if everything can work together.
>
> -Jason
>
> On Wed, 10 May 2000, Matthew Pocock wrote:
>
> > Do you know if the java server <-> perl client works? (or, for that matter, perl
> > server <-> java client). Am I getting ahead of myself?
> >
> > Matthew
> >
> >
> >
>
> 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/
>
> _______________________________________________
> Biojava-l mailing list - Biojava-l@biojava.org
> http://biojava.org/mailman/listinfo/biojava-l
--__--__--
_______________________________________________
Biojava-l mailing list - Biojava-l@biojava.org
http://biojava.org/mailman/listinfo/biojava-l
End of Biojava-l Digest