[Biocorba-l] Biocorba-0.2.0 - A proposal

[Brad Chapman]

Hi Alan!
Thanks for getting back with me.

> > *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).
> 
> I was being honest. I don't use python and hadn't implemented the IDL with
> it, so I didn't include it. If you knock up a client or server in Python,
> then this should be added to the list immediately. (There is, of course,
> nothing in this IDL that prevents a Python client/server - I just didn't
> want to prempt the statement). Perhaps we change the statement to the
> effect that the IDL is CORBA2.2 compliant, and hence workable with the
> following ORBs,...

Sorry, I was re-reading what I wrote, and I didn't mean to actually
sound upset -- I hope it didn't come across that way. I was just
trying to play the "poor-neglected-python-progammer" role for some
sympathy :-). Seriously, though, I think it is good to mention that it 
works with particular languages and has been tested with them, I just
think we should also throw python into the list! 

In terms of the CORBA version number, I think you can even drop
further back and say that an ORB implementation only needs to be 2.0
compliant and be fairly safe. Fnorb, is "a CORBA 2.0 ORB written in
python" (development on it has been stalled for quite a while now) and 
seems to handle the IDL with no problems.

[my proposal for getting rid of boolean switch for including sub_SeqFeatures]
> Probably someone authorative from the bioperl community should comment on
> this. The EMBL database does not have the concept of sub-SeqFeatures.
> However, I could imagine it would be useful to be able to step through
> different layers of sub_SeqFeatures individually (boolean=false), as well

Oh I agree! I am definately for including sub_SeqFeatures, I just
thought we might be able to get rid of the switch for including them
and always include them, to make things simpler.

> as getting them all at once (boolean=true). The latter is useful for
> understanding the hierarchical relationship between features and their
> sub-features.

Hmmm, I guess I don't understand what the switch does exactly
then. Does it:

a. Make the sub-SeqFeatures available through the sub_SeqFeatures()
(ie. if you don't have a True for sub_seqfeatures sub_SeqFeatures()
will return nothing).

b. Flatten all of the features so that they are all top level and
there are no sub_SeqFeatures()

I thought that it meant a. originally, but now I am really
confused... Anyways, I would like to always see the behavior of having 
sub_SeqFeatures() and just drop out the boolean value to avoid having
to deal with it (ie. so I won't get so confused :-).

[using dates instead of traditional versions like 0.2 for *SeqDBs]
> Ewan, Matt and I did discuss this very issue - we'd thought about
> suggesting unix timestamps, or alternatively, '2000-01-03' becomes
> '20000103'

True, I could do this with the long datatype we have now -- good
point.
 
> A potential backdoor solution is that each SeqDB object has a 'string'
> description field (which would be kind of useful anyway). This could hold
> your stringified date.

This would also be fine with me. 

> I am concerned that with a string version, people may misuse the version.

This is true -- then you could version using "secret code names" or 
something like that if you were feeling extra cute.

I guess my opinion is that we could just stick with the long and you
could either version with "traditional" versions like 0.2, 0.3,
... or use unix timestamps if dates are more approriate. So, I guess I 
withdraw my plea to use strings :-).

[moving the ref/unref inside the biocorba module]
> I don't bother to implement this, as the EMBL server already has an object
> evictor implemented. In terms of re-use, the current approach is a good
> thing. However, you are right about the mismatch with the
> query_interface() method.

Hmmm. I guess I don't see the advantages of leaving it outside the
biocorba module, but I'm that pushy -- I can live with it either way
-- it was a thought I had.

Thanks again for getting bck with me! Talk to you soon.

Brad