[Biojava-l] RE: Biojava-l digest, Vol 1 #23 - 4 msgs

Mon, 14 Feb 2000 12:08:36 +0000

Glad to see lots of discussion and good work here. Most implementations of
standards are based on adapters to existing code. Short of a direct
implementation of CORBA skeletons (which isn't always a good idea if you later
chose to change comms model) there's always going to be some level of
adaptation. Obvoisuly performance degrades the more adaptations you have. One
way to circumvent the internal IDL issue would be to use the RMI over IIOP
model, which supports valuetypes (because RMI does pass-by-value), this gives
IDL which is more Java-friendly. In the end of the day it doesn't matter how
many internal interfaces you have provided the end implementation works,
supports the IDL and isn't too slow.

The main thing standing in the way of a free BSA IDL impl is the valuetypes -
perhaps using RMI/IIOP would solve this problem? There are free implementations
of events, naming - so the other services shouldn't be a problem.

Tim

birney@ebi.ac.uk on 13-Feb-2000 17:20

To:   mdickson
cc:   biojava-l, smarkel (bcc: Timothy W Slidel/CIS/PHRD/SB_PLC)
Subject:  Re: [Biojava-l] RE: Biojava-l digest, Vol 1 #23 - 4 msgs

>
> I'll be honest, I was fairly disappointed with the emergence of a new
> IDL to express sequences.  Ewan made a comment on this list suggesting
> that an effort to provide a mapping between the LSR model and the new
> one might be a nice thing to do. I guess I have an alternate view on
> this.  If the community at large would like to encourage vendors to
> participate in OpenSource/Community Source or general *open* efforts,
> it might be better to encourage the the use of the standards work that
> has been done instead of continuing to invent alternatives.  Of course
> most any position can be rationalized and there might be very good
> reasons for doing sonmething different.  NetGenics' SYNERGY is
> different that the LSR model.  I *am* commited to migrate to it and
> for those things I don't like I'll continue to try to work
> constructively for changes.  I'd like to believe that others would
> make a similar commitment.

Mike -

I appreciate your concerns and directness.

the problem about the LSR model is that it is *simply not friendly* to
free and open source CORBA implementations and it requires alot of
implementation effort by the server writers to provide something.
This puts a high barrier of entry to people using this.

(let me remind you that LSR uses alot of valuetypes, which are
not available in most free orbs and in particular the perl and python
orbs, and the Cos:: definitions, which are both not available in
free orbs and pain to implement oneself. The specification is too
high, too focused on bought-in components and too focused on
enterprise level interoperability to make any sense for academic
code interoperability).

>
> The problem with bridges and adaptors is that as we try to solve
> higher order problems that require extensions the adaptor approach
> becomes combanitoric. Having a solid base to build on that is
> consistent is pretty much a requirement if your goal is
> interoperability.  Hence my commitment to the LSR.

>
> The implementation classes used in Synergy will probably mostly stay the
> same as we move to the LSR model.  That is, we hava strong seperation of
> interface and implementation.  Having *implementation* centric IDL just
> seems silly to me.   If you want implementation centric interfaces with Java
> as the target language then use Java interfaces for that purpose.

I disagree. It is quite sensible to have internal interfaces which
represent what is or is not able to do, and why not make them CORBA
IDL interfaces? That is what alot of other projects do (eg, GNOME).
CORBA does not have to be restricted to an enterprise-only, client
friendly interfaces, but can also be used in internal software for
server friendly IDLs. CORBA can be used for more than the last mile...

I am committed to BSA-LSR, and I want to make it work. When I looked at
providing bioperl as a BSA-LSR style set of interfaces I realised the
best way to do this was to have internal interfaces which I then built
a bridge layer in Java to BSA. *I cannot see any other way of doing this*.
(maybe you can). I see no problem in either sharing that idea of an
internal interface nor encouraging other people to help write the bridge.

If you want to hit the LSR specification directly from bioperl, please
tell me how to do it, because I don't think it is possible.

>
> Sorry for being so direct.  That's my style.  I've been following biojava
> for a little while now and there is some very excellent work being done.
> I'd love to see it interoperate and leverage the very excellent work we did
> in the LSR.  I just have a different idea of how that should happen.
>
> Mike Dickson
> mdickson@netgenics.com
>
> _______________________________________________
> 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