Issue 3437: Biomolecular FTF issue: orb.idl (biomolecular-ftf) Source: Japan Biological Informatics Consortium (Mr. Martin Senger, martin.senger@gmail.com) Nature: Severity: Summary: The corba spec says (in chapter 3.14 "CORBA Module") that "the file orb.idl must be included in IDL files that use names defined in the CORBA module". Our spec does contain (in module DsLSRAnalysis) CORBA::TypeCode. So I guess that we should have also #include <orb.idl> there. Some ORBs may not compile it properly without it. Resolution: accepted Revised Text: Add "#include " to the #include list at the beginning of section 2.2.1. Include it again in the individual descriptions found in the succeeding paragraphs. Add it again in section C.2. Actions taken: March 21, 2000: receive dissue May 24, 2001: closed issue Discussion: End of Annotations:===== ate: Mon, 21 Feb 2000 13:53:56 +0000 (GMT) From: Martin Senger To: biomolecular-ftf@emerald.omg.org cc: Philip Lijnzaad Subject: truncatable valuetypes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: $7~e9I0_d9Y/4!!S8md9 It seems to me that we have an error (or errors) in our spec. If I am right I would like to bring this issue to the attention of the FTF during Denver meeting. Please help me to find if I am mistaken or not. My understanding is that for being able to extend BSA spec by introducing new valuetypes as subclasses of the existing (in BSA spec) valuetypes, we need to use "truncatable" in our spec. Having it the "extended" servers can still provide sub-classed valuetypes to the "dumb" clients (those who understand only the original valuetype). But without this keyword the extended servers can work only with extended clients. Which is not what we wanted (remember the discussion with Oxford Molec. about it). Also the BSA document says in 1.4.1 that we are going to use "truncatable". However, we did not. Thanks for your comments. Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger Date: Tue, 21 Mar 2000 11:20:10 -0800 From: Scott Markel Organization: NetGenics, Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: biomolecular-ftf@emerald.omg.org Subject: Re: issue 3336 -- Biomolecular FTF issue References: <4.1.20000320163305.00b41500@emerald.omg.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: W!! I think that our IDL is correct and that the text in section 1.4.1 is not. In our IDL we have not used truncatable. I think this is appropriate since we've used valuetypes as extensible structs. For an implementation that wants to extend a BSA valuetype, the truncatable keyword is part of the declaration of the extension, not part of the BSA declaration. For example, module DsLSRAnalysis { valuetype AnalysisType { // stuff goes here }; }; module MyBSAExtensions { valuetype MyAnalysisType : truncatable DsLSRAnalysis::AnalysisType { // extension stuff goes here // "truncatable" says this stuff can be ignored with impunity }; }; I think the text in section 1.4.1 should be changed by removing the last bullet. Scott Juergen Boldt wrote: > > This is issue # 3336 > > truncatable valuetypes > > It seems to me that we have an error (or errors) in our spec. If I > am > right I would like to bring this issue to the attention of the FTF > during > Denver meeting. > Please help me to find if I am mistaken or not. > > My understanding is that for being able to extend BSA spec by > introducing new valuetypes as subclasses of the existing (in BSA > spec) valuetypes, we need to use "truncatable" in our spec. Having > it the > "extended" servers can still provide sub-classed valuetypes to the > "dumb" > clients (those who understand only the original valuetype). But > without > this keyword the extended servers can work only with extended > clients. > Which is not what we wanted (remember the discussion with Oxford > Molec. > about it). > Also the BSA document says in 1.4.1 that we are going to use > "truncatable". However, we did not. -- Scott Markel, Ph.D. NetGenics, Inc. smarkel@netgenics.com 4350 Executive Drive Tel: 858 455 5223 Suite 260 FAX: 858 455 1388 San Diego, CA 92121 Date: Tue, 21 Mar 2000 19:52:11 +0000 (GMT) From: Martin Senger To: Scott Markel cc: biomolecular-ftf@emerald.omg.org, Philip Lijnzaad Subject: Re: issue 3336 -- Biomolecular FTF issue In-Reply-To: <38D7CB6A.C6807E27@netgenics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Ia[d9=j8!!9@F!!<)'!! > > For an implementation that wants to extend a BSA valuetype, the > truncatable keyword is part of the declaration of the extension, not > part of the BSA declaration. > You are probably right but I need to run some more tests to be sure about it - so please do not rush with voting on this issue. Also it might be useful to think why we put "truncatable" in the subtypes in genomic maps spec. Was it on purpose, or we simply did not understand it enough? If it was on purpose we may consider to put "truncatable" in bsa as well - for subtypes I mean, not for the root valuetypes. Regards, Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger Date: Tue, 21 Mar 2000 12:04:08 -0800 From: Scott Markel Organization: NetGenics, Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Martin Senger CC: biomolecular-ftf@emerald.omg.org, Philip Lijnzaad Subject: Re: issue 3336 -- Biomolecular FTF issue References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: U!`d92o$e9TCF!!Pfd!! Martin, Martin Senger wrote: > You are probably right but I need to run some more tests to be sure > about it - so please do not rush with voting on this issue. Not to worry. I'm not going to rush. Scott -- Scott Markel, Ph.D. NetGenics, Inc. smarkel@netgenics.com 4350 Executive Drive Tel: 858 455 5223 Suite 260 FAX: 858 455 1388 San Diego, CA 92121 Date: Wed, 19 Jul 2000 01:20:16 +0100 (BST) From: Martin Senger To: biomolecular-ftf@emerald.omg.org Subject: truncatable valuetypes In-Reply-To: <4.2.0.58.20000707151921.00bc05c0@emerald.omg.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: MR!e9k/K!!DQ6e9<3K!! Hi, I know that I was discussing this issue some time ago, but I do not remember if it made an issue. I think not - otherwise, I am sorry to repeat it. However, now I surely have much more understanding of it and now I am quite sure that our specification is wrong (in a small "detail"). We have several types of AnalysisEvents. They are valuetypes and they are not "truncatable". Which means that client has to deal with that subtype which is actually sent, not only with a super-type. Our specification says that server may send various types of events, and client must be prepared to ignore those he is not interested in. Which I think is not possible without having our analysis event subtypes "truncatable". Let me explain it: We are sending these events in two forms. First one, more used, are events wrapped in a CORBA any (using an EventChannel). Here we do not need "truncatable", indeed. The client gets "any" and can check repository id of the wrapped object, and depending on this id he may decide to extract it or ignore it. And only for extraction from "any" the client needs a registered factory for the particular event type. So, if he sees a type he had not registered a factory for, he ignores it. The second place is "last_event" in AnalysisInstance. And here we have a problem. Here server does not send an "any" but directly an instance of AnalysisEvent. Which may be (and often will be) an instance of a more specilized subtype. A client does not see this instance until it is unmarshalled - but it is too late. If the event contains a subtype for which the client is not prepared, a marshalling error occurs. But if we have "truncatable" then everything is okay - the factory for "higher" type can unmarshall the subtype (and truncates everything not known to that "higher" type). Therefore, my suggestion is to put "truncatable" to valuetypes StateChangedEvent, HeartbeatProgressEvent, PercentProgressEvent, TimeProgressEvent, and StepProgressEvent. Regards, Martin P.S. The guys dealing with BioObjects may find the similar issue for interval and SeqRegion I guess. M. -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger