Sylvain tried to add the 'Exception' state to the corba IDL, but 'Exception'
is a reserved word in IDL.
C++:
enum TaskState {PreOperational, Stopped,...,Exception,...};
IDL:
enum CTaskState {PreOperational, Stopped,..., ??? ,...};
He proposed 'ExceptionState' or 'Exceptional'. I thought more of
'ExceptionCaught'. The names in corba must match the names in C++ to avoid
confusion, so any update in the IDL will be reflected at the C++ level.
Another alternative is to also perfix the enum values with a 'C' as is done
with all 'CORBA' types to avoid conflicts with the C++ type when both headers
and namespaces are used.
So we could also get:
C++:
enum TaskState {PreOperational, Stopped,...,Exception,...};
IDL:
enum CTaskState {CPreOperational, CStopped,..., CException ,...};
Maybe for consistency reasons this last one's best... thoughts ?
Peter
Name clash in component state names
+1 on the C prefix
Name clash in component state names
On Wed, 11 Aug 2010, Peter Soetens wrote:
> Sylvain tried to add the 'Exception' state to the corba IDL, but 'Exception'
> is a reserved word in IDL.
>
> C++:
> enum TaskState {PreOperational, Stopped,...,Exception,...};
>
> IDL:
> enum CTaskState {PreOperational, Stopped,..., ??? ,...};
>
> He proposed 'ExceptionState' or 'Exceptional'. I thought more of
> 'ExceptionCaught'. The names in corba must match the names in C++ to avoid
> confusion, so any update in the IDL will be reflected at the C++ level.
>
> Another alternative is to also perfix the enum values with a 'C' as is done
> with all 'CORBA' types to avoid conflicts with the C++ type when both headers
> and namespaces are used.
>
> So we could also get:
>
> C++:
> enum TaskState {PreOperational, Stopped,...,Exception,...};
>
> IDL:
> enum CTaskState {CPreOperational, CStopped,..., CException ,...};
>
> Maybe for consistency reasons this last one's best... thoughts ?
"C"-prefix -> "IDL"-prefix, since that's more portable between middlewares.
Or just "I", similar to the Java practice of prefixing abstract interface
names (which is very much what you are doing in this particular case, isn't
it?)
Herman
Name clash in component state names
On Wednesday 11 August 2010 09:54:57 Herman Bruyninckx wrote:
> On Wed, 11 Aug 2010, Peter Soetens wrote:
> > Sylvain tried to add the 'Exception' state to the corba IDL, but
> > 'Exception' is a reserved word in IDL.
> >
> > C++:
> > enum TaskState {PreOperational, Stopped,...,Exception,...};
> >
> > IDL:
> > enum CTaskState {PreOperational, Stopped,..., ??? ,...};
> >
> > He proposed 'ExceptionState' or 'Exceptional'. I thought more of
> > 'ExceptionCaught'. The names in corba must match the names in C++ to
> > avoid confusion, so any update in the IDL will be reflected at the C++
> > level.
> >
> > Another alternative is to also perfix the enum values with a 'C' as is
> > done with all 'CORBA' types to avoid conflicts with the C++ type when
> > both headers and namespaces are used.
> >
> > So we could also get:
> >
> > C++:
> > enum TaskState {PreOperational, Stopped,...,Exception,...};
> >
> > IDL:
> > enum CTaskState {CPreOperational, CStopped,..., CException ,...};
> >
> > Maybe for consistency reasons this last one's best... thoughts ?
>
> "C"-prefix -> "IDL"-prefix, since that's more portable between middlewares.
> Or just "I", similar to the Java practice of prefixing abstract interface
> names (which is very much what you are doing in this particular case, isn't
> it?)
Well yes and no. This idl was only and specifically written for the CORBA
transport, it also contains very corba specific constructs (like anys and the
corba exceptions). It's by no means abstract, it really assumes corba is used.
That's why we use the 'C' prefix. The prefix only serves to avoid name clashes
when using 'c++ using namespace' directives when writing mixed corba/C++ code.
Peter
Name clash in component state names
On Wed, 11 Aug 2010, Peter Soetens wrote:
> On Wednesday 11 August 2010 09:54:57 Herman Bruyninckx wrote:
>> On Wed, 11 Aug 2010, Peter Soetens wrote:
>>> Sylvain tried to add the 'Exception' state to the corba IDL, but
>>> 'Exception' is a reserved word in IDL.
>>>
>>> C++:
>>> enum TaskState {PreOperational, Stopped,...,Exception,...};
>>>
>>> IDL:
>>> enum CTaskState {PreOperational, Stopped,..., ??? ,...};
>>>
>>> He proposed 'ExceptionState' or 'Exceptional'. I thought more of
>>> 'ExceptionCaught'. The names in corba must match the names in C++ to
>>> avoid confusion, so any update in the IDL will be reflected at the C++
>>> level.
>>>
>>> Another alternative is to also perfix the enum values with a 'C' as is
>>> done with all 'CORBA' types to avoid conflicts with the C++ type when
>>> both headers and namespaces are used.
>>>
>>> So we could also get:
>>>
>>> C++:
>>> enum TaskState {PreOperational, Stopped,...,Exception,...};
>>>
>>> IDL:
>>> enum CTaskState {CPreOperational, CStopped,..., CException ,...};
>>>
>>> Maybe for consistency reasons this last one's best... thoughts ?
>>
>> "C"-prefix -> "IDL"-prefix, since that's more portable between middlewares.
>> Or just "I", similar to the Java practice of prefixing abstract interface
>> names (which is very much what you are doing in this particular case, isn't
>> it?)
>
> Well yes and no. This idl was only and specifically written for the CORBA
> transport, it also contains very corba specific constructs (like anys and the
> corba exceptions). It's by no means abstract, it really assumes corba is used.
> That's why we use the 'C' prefix. The prefix only serves to avoid name clashes
> when using 'c++ using namespace' directives when writing mixed corba/C++ code.
Well yes an no. :-) While it _is_ CORBA-specific IDL, it will be very close
to any kind of IDL that will be supported in the future; the ROS "IDL"
being the first one. Maybe adding two prefixes would be most flexible:
- one to make the distinction between an abstract _model_ of the messages
This could be the "I", or the "M" standing for "meta", "model".
- one to indicate the "model context", such as CORBA, ROS,... With "C",
"R",... as appropriate prefixes (I prefer to use more than one letter to
indicate the model context...)
Herman
Name clash in component state names
Herman Bruyninckx wrote:
> On Wed, 11 Aug 2010, Peter Soetens wrote:
>
>
>> On Wednesday 11 August 2010 09:54:57 Herman Bruyninckx wrote:
>>
>>> On Wed, 11 Aug 2010, Peter Soetens wrote:
>>>
>>>> Sylvain tried to add the 'Exception' state to the corba IDL, but
>>>> 'Exception' is a reserved word in IDL.
>>>>
>>>> C++:
>>>> enum TaskState {PreOperational, Stopped,...,Exception,...};
>>>>
>>>> IDL:
>>>> enum CTaskState {PreOperational, Stopped,..., ??? ,...};
>>>>
>>>> He proposed 'ExceptionState' or 'Exceptional'. I thought more of
>>>> 'ExceptionCaught'. The names in corba must match the names in C++ to
>>>> avoid confusion, so any update in the IDL will be reflected at the C++
>>>> level.
>>>>
>>>> Another alternative is to also perfix the enum values with a 'C' as is
>>>> done with all 'CORBA' types to avoid conflicts with the C++ type when
>>>> both headers and namespaces are used.
>>>>
>>>> So we could also get:
>>>>
>>>> C++:
>>>> enum TaskState {PreOperational, Stopped,...,Exception,...};
>>>>
>>>> IDL:
>>>> enum CTaskState {CPreOperational, CStopped,..., CException ,...};
>>>>
>>>> Maybe for consistency reasons this last one's best... thoughts ?
>>>>
>>> "C"-prefix -> "IDL"-prefix, since that's more portable between middlewares.
>>> Or just "I", similar to the Java practice of prefixing abstract interface
>>> names (which is very much what you are doing in this particular case, isn't
>>> it?)
>>>
>> Well yes and no. This idl was only and specifically written for the CORBA
>> transport, it also contains very corba specific constructs (like anys and the
>> corba exceptions). It's by no means abstract, it really assumes corba is used.
>> That's why we use the 'C' prefix. The prefix only serves to avoid name clashes
>> when using 'c++ using namespace' directives when writing mixed corba/C++ code.
>>
>
> Well yes an no. :-) While it _is_ CORBA-specific IDL, it will be very close
> to any kind of IDL that will be supported in the future; the ROS "IDL"
> being the first one. Maybe adding two prefixes would be most flexible:
> - one to make the distinction between an abstract _model_ of the messages
> This could be the "I", or the "M" standing for "meta", "model".
> - one to indicate the "model context", such as CORBA, ROS,... With "C",
> "R",... as appropriate prefixes (I prefer to use more than one letter to
> indicate the model context...)
>
And what about we actually solve actual problems instead of
over-engineering RTT (even more that it was in 1.x) ? If you want to do
meta-modelling, then -- anyway -- you will do it in a meta-model
language and will be able to remove any prefix there, so why bother
overloading the RTT's CORBA IDL with whatever might or might not happen ?
CORBA IDL *is* CORBA IDL. It is not a meta-modelling language, it is a
CORBA-specific definition language.
Name clash in component state names
On Thu, 12 Aug 2010, Sylvain Joyeux wrote:
> Herman Bruyninckx wrote:
>> On Wed, 11 Aug 2010, Peter Soetens wrote:
>>
>>
>>> On Wednesday 11 August 2010 09:54:57 Herman Bruyninckx wrote:
>>>
>>>> On Wed, 11 Aug 2010, Peter Soetens wrote:
>>>>
>>>>> Sylvain tried to add the 'Exception' state to the corba IDL, but
>>>>> 'Exception' is a reserved word in IDL.
>>>>>
>>>>> C++:
>>>>> enum TaskState {PreOperational, Stopped,...,Exception,...};
>>>>>
>>>>> IDL:
>>>>> enum CTaskState {PreOperational, Stopped,..., ??? ,...};
>>>>>
>>>>> He proposed 'ExceptionState' or 'Exceptional'. I thought more of
>>>>> 'ExceptionCaught'. The names in corba must match the names in C++ to
>>>>> avoid confusion, so any update in the IDL will be reflected at the C++
>>>>> level.
>>>>>
>>>>> Another alternative is to also perfix the enum values with a 'C' as is
>>>>> done with all 'CORBA' types to avoid conflicts with the C++ type when
>>>>> both headers and namespaces are used.
>>>>>
>>>>> So we could also get:
>>>>>
>>>>> C++:
>>>>> enum TaskState {PreOperational, Stopped,...,Exception,...};
>>>>>
>>>>> IDL:
>>>>> enum CTaskState {CPreOperational, CStopped,..., CException ,...};
>>>>>
>>>>> Maybe for consistency reasons this last one's best... thoughts ?
>>>>>
>>>> "C"-prefix -> "IDL"-prefix, since that's more portable between middlewares.
>>>> Or just "I", similar to the Java practice of prefixing abstract interface
>>>> names (which is very much what you are doing in this particular case, isn't
>>>> it?)
>>>>
>>> Well yes and no. This idl was only and specifically written for the CORBA
>>> transport, it also contains very corba specific constructs (like anys and the
>>> corba exceptions). It's by no means abstract, it really assumes corba is used.
>>> That's why we use the 'C' prefix. The prefix only serves to avoid name clashes
>>> when using 'c++ using namespace' directives when writing mixed corba/C++ code.
>>>
>>
>> Well yes an no. :-) While it _is_ CORBA-specific IDL, it will be very close
>> to any kind of IDL that will be supported in the future; the ROS "IDL"
>> being the first one. Maybe adding two prefixes would be most flexible:
>> - one to make the distinction between an abstract _model_ of the messages
>> This could be the "I", or the "M" standing for "meta", "model".
>> - one to indicate the "model context", such as CORBA, ROS,... With "C",
>> "R",... as appropriate prefixes (I prefer to use more than one letter to
>> indicate the model context...)
>>
> And what about we actually solve actual problems instead of
> over-engineering RTT (even more that it was in 1.x) ? If you want to do
> meta-modelling, then -- anyway -- you will do it in a meta-model
> language and will be able to remove any prefix there, so why bother
> overloading the RTT's CORBA IDL with whatever might or might not happen ?
>
> CORBA IDL *is* CORBA IDL. It is not a meta-modelling language, it is a
> CORBA-specific definition language.
Yes, but RTT already gives way too much the impression that it is tied to
CORBA! And that is a significant part of the "overengineering" that you
mention (and that I agree with): 1.x was very influenced by CORBA, and we
now pay the price for that...
I think we should get CORBA _completely_ out of sight in RTT, and move it
to a new kind of Orocos-subproject ("middleware bindings" or something like
that). If we keep it in the RTT scope, anything that is added to RTT should
be CORBA independent, hence my suggestion to introduce a "meta model"
description, of which the CORBA IDL would just be a concrete instantiation.
Herman
Name clash in component state names
On Thursday 12 August 2010 11:26:14 Herman Bruyninckx wrote:
> On Thu, 12 Aug 2010, Sylvain Joyeux wrote:
> > Herman Bruyninckx wrote:
> >> On Wed, 11 Aug 2010, Peter Soetens wrote:
> >>> On Wednesday 11 August 2010 09:54:57 Herman Bruyninckx wrote:
> >>>> On Wed, 11 Aug 2010, Peter Soetens wrote:
> >>>>> Sylvain tried to add the 'Exception' state to the corba IDL, but
> >>>>> 'Exception' is a reserved word in IDL.
> >>>>>
> >>>>> C++:
> >>>>> enum TaskState {PreOperational, Stopped,...,Exception,...};
> >>>>>
> >>>>> IDL:
> >>>>> enum CTaskState {PreOperational, Stopped,..., ??? ,...};
> >>>>>
> >>>>> He proposed 'ExceptionState' or 'Exceptional'. I thought more of
> >>>>> 'ExceptionCaught'. The names in corba must match the names in C++ to
> >>>>> avoid confusion, so any update in the IDL will be reflected at the
> >>>>> C++ level.
> >>>>>
> >>>>> Another alternative is to also perfix the enum values with a 'C' as
> >>>>> is done with all 'CORBA' types to avoid conflicts with the C++ type
> >>>>> when both headers and namespaces are used.
> >>>>>
> >>>>> So we could also get:
> >>>>>
> >>>>> C++:
> >>>>> enum TaskState {PreOperational, Stopped,...,Exception,...};
> >>>>>
> >>>>> IDL:
> >>>>> enum CTaskState {CPreOperational, CStopped,..., CException ,...};
> >>>>>
> >>>>> Maybe for consistency reasons this last one's best... thoughts ?
> >>>>
> >>>> "C"-prefix -> "IDL"-prefix, since that's more portable between
> >>>> middlewares. Or just "I", similar to the Java practice of prefixing
> >>>> abstract interface names (which is very much what you are doing in
> >>>> this particular case, isn't it?)
> >>>
> >>> Well yes and no. This idl was only and specifically written for the
> >>> CORBA transport, it also contains very corba specific constructs (like
> >>> anys and the corba exceptions). It's by no means abstract, it really
> >>> assumes corba is used. That's why we use the 'C' prefix. The prefix
> >>> only serves to avoid name clashes when using 'c++ using namespace'
> >>> directives when writing mixed corba/C++ code.
> >>
> >> Well yes an no. :-) While it _is_ CORBA-specific IDL, it will be very
> >> close to any kind of IDL that will be supported in the future; the ROS
> >> "IDL" being the first one. Maybe adding two prefixes would be most
> >> flexible: - one to make the distinction between an abstract _model_ of
> >> the messages This could be the "I", or the "M" standing for "meta",
> >> "model". - one to indicate the "model context", such as CORBA, ROS,...
> >> With "C", "R",... as appropriate prefixes (I prefer to use more than one
> >> letter to indicate the model context...)
> >
> > And what about we actually solve actual problems instead of
> > over-engineering RTT (even more that it was in 1.x) ? If you want to do
> > meta-modelling, then -- anyway -- you will do it in a meta-model
> > language and will be able to remove any prefix there, so why bother
> > overloading the RTT's CORBA IDL with whatever might or might not happen ?
> >
> > CORBA IDL *is* CORBA IDL. It is not a meta-modelling language, it is a
> > CORBA-specific definition language.
>
> Yes, but RTT already gives way too much the impression that it is tied to
> CORBA! And that is a significant part of the "overengineering" that you
> mention (and that I agree with): 1.x was very influenced by CORBA, and we
> now pay the price for that...
>
> I think we should get CORBA _completely_ out of sight in RTT, and move it
> to a new kind of Orocos-subproject ("middleware bindings" or something like
> that). If we keep it in the RTT scope, anything that is added to RTT should
> be CORBA independent, hence my suggestion to introduce a "meta model"
> description, of which the CORBA IDL would just be a concrete instantiation.
The IDL we are talking about is part of the corba transport and would be moved
out of RTT as well then. It is 'the interface of the corba transport'. Our
conceptual model of an RTT component is what is being developed at
Leuven/Brics right now :-)
Peter
Name clash in component state names
Peter Soetens wrote:
> On Thursday 12 August 2010 11:26:14 Herman Bruyninckx wrote:
>
>> On Thu, 12 Aug 2010, Sylvain Joyeux wrote:
>>
>>> Herman Bruyninckx wrote:
>>>
>>>> On Wed, 11 Aug 2010, Peter Soetens wrote:
>>>>
>>>>> On Wednesday 11 August 2010 09:54:57 Herman Bruyninckx wrote:
>>>>>
>>>>>> On Wed, 11 Aug 2010, Peter Soetens wrote:
>>>>>>
>>>>>>> Sylvain tried to add the 'Exception' state to the corba IDL, but
>>>>>>> 'Exception' is a reserved word in IDL.
>>>>>>>
>>>>>>> C++:
>>>>>>> enum TaskState {PreOperational, Stopped,...,Exception,...};
>>>>>>>
>>>>>>> IDL:
>>>>>>> enum CTaskState {PreOperational, Stopped,..., ??? ,...};
>>>>>>>
>>>>>>> He proposed 'ExceptionState' or 'Exceptional'. I thought more of
>>>>>>> 'ExceptionCaught'. The names in corba must match the names in C++ to
>>>>>>> avoid confusion, so any update in the IDL will be reflected at the
>>>>>>> C++ level.
>>>>>>>
>>>>>>> Another alternative is to also perfix the enum values with a 'C' as
>>>>>>> is done with all 'CORBA' types to avoid conflicts with the C++ type
>>>>>>> when both headers and namespaces are used.
>>>>>>>
>>>>>>> So we could also get:
>>>>>>>
>>>>>>> C++:
>>>>>>> enum TaskState {PreOperational, Stopped,...,Exception,...};
>>>>>>>
>>>>>>> IDL:
>>>>>>> enum CTaskState {CPreOperational, CStopped,..., CException ,...};
>>>>>>>
>>>>>>> Maybe for consistency reasons this last one's best... thoughts ?
>>>>>>>
>>>>>> "C"-prefix -> "IDL"-prefix, since that's more portable between
>>>>>> middlewares. Or just "I", similar to the Java practice of prefixing
>>>>>> abstract interface names (which is very much what you are doing in
>>>>>> this particular case, isn't it?)
>>>>>>
>>>>> Well yes and no. This idl was only and specifically written for the
>>>>> CORBA transport, it also contains very corba specific constructs (like
>>>>> anys and the corba exceptions). It's by no means abstract, it really
>>>>> assumes corba is used. That's why we use the 'C' prefix. The prefix
>>>>> only serves to avoid name clashes when using 'c++ using namespace'
>>>>> directives when writing mixed corba/C++ code.
>>>>>
>>>> Well yes an no. :-) While it _is_ CORBA-specific IDL, it will be very
>>>> close to any kind of IDL that will be supported in the future; the ROS
>>>> "IDL" being the first one. Maybe adding two prefixes would be most
>>>> flexible: - one to make the distinction between an abstract _model_ of
>>>> the messages This could be the "I", or the "M" standing for "meta",
>>>> "model". - one to indicate the "model context", such as CORBA, ROS,...
>>>> With "C", "R",... as appropriate prefixes (I prefer to use more than one
>>>> letter to indicate the model context...)
>>>>
>>> And what about we actually solve actual problems instead of
>>> over-engineering RTT (even more that it was in 1.x) ? If you want to do
>>> meta-modelling, then -- anyway -- you will do it in a meta-model
>>> language and will be able to remove any prefix there, so why bother
>>> overloading the RTT's CORBA IDL with whatever might or might not happen ?
>>>
>>> CORBA IDL *is* CORBA IDL. It is not a meta-modelling language, it is a
>>> CORBA-specific definition language.
>>>
>> Yes, but RTT already gives way too much the impression that it is tied to
>> CORBA! And that is a significant part of the "overengineering" that you
>> mention (and that I agree with): 1.x was very influenced by CORBA, and we
>> now pay the price for that...
>>
>> I think we should get CORBA _completely_ out of sight in RTT, and move it
>> to a new kind of Orocos-subproject ("middleware bindings" or something like
>> that). If we keep it in the RTT scope, anything that is added to RTT should
>> be CORBA independent, hence my suggestion to introduce a "meta model"
>> description, of which the CORBA IDL would just be a concrete instantiation.
>>
>
> The IDL we are talking about is part of the corba transport and would be moved
> out of RTT as well then. It is 'the interface of the corba transport'. Our
> conceptual model of an RTT component is what is being developed at
> Leuven/Brics right now :-)
>
Since everyone in the thread agrees, I updated the merge request ...
Name clash in component state names
On Thu, 12 Aug 2010, Sylvain Joyeux wrote:
> Peter Soetens wrote:
>> On Thursday 12 August 2010 11:26:14 Herman Bruyninckx wrote:
>>
>>> On Thu, 12 Aug 2010, Sylvain Joyeux wrote:
>>>
>>>> Herman Bruyninckx wrote:
>>>>
>>>>> On Wed, 11 Aug 2010, Peter Soetens wrote:
>>>>>
>>>>>> On Wednesday 11 August 2010 09:54:57 Herman Bruyninckx wrote:
>>>>>>
>>>>>>> On Wed, 11 Aug 2010, Peter Soetens wrote:
>>>>>>>
>>>>>>>> Sylvain tried to add the 'Exception' state to the corba IDL, but
>>>>>>>> 'Exception' is a reserved word in IDL.
>>>>>>>>
>>>>>>>> C++:
>>>>>>>> enum TaskState {PreOperational, Stopped,...,Exception,...};
>>>>>>>>
>>>>>>>> IDL:
>>>>>>>> enum CTaskState {PreOperational, Stopped,..., ??? ,...};
>>>>>>>>
>>>>>>>> He proposed 'ExceptionState' or 'Exceptional'. I thought more of
>>>>>>>> 'ExceptionCaught'. The names in corba must match the names in C++ to
>>>>>>>> avoid confusion, so any update in the IDL will be reflected at the
>>>>>>>> C++ level.
>>>>>>>>
>>>>>>>> Another alternative is to also perfix the enum values with a 'C' as
>>>>>>>> is done with all 'CORBA' types to avoid conflicts with the C++ type
>>>>>>>> when both headers and namespaces are used.
>>>>>>>>
>>>>>>>> So we could also get:
>>>>>>>>
>>>>>>>> C++:
>>>>>>>> enum TaskState {PreOperational, Stopped,...,Exception,...};
>>>>>>>>
>>>>>>>> IDL:
>>>>>>>> enum CTaskState {CPreOperational, CStopped,..., CException ,...};
>>>>>>>>
>>>>>>>> Maybe for consistency reasons this last one's best... thoughts ?
>>>>>>>>
>>>>>>> "C"-prefix -> "IDL"-prefix, since that's more portable between
>>>>>>> middlewares. Or just "I", similar to the Java practice of prefixing
>>>>>>> abstract interface names (which is very much what you are doing in
>>>>>>> this particular case, isn't it?)
>>>>>>>
>>>>>> Well yes and no. This idl was only and specifically written for the
>>>>>> CORBA transport, it also contains very corba specific constructs (like
>>>>>> anys and the corba exceptions). It's by no means abstract, it really
>>>>>> assumes corba is used. That's why we use the 'C' prefix. The prefix
>>>>>> only serves to avoid name clashes when using 'c++ using namespace'
>>>>>> directives when writing mixed corba/C++ code.
>>>>>>
>>>>> Well yes an no. :-) While it _is_ CORBA-specific IDL, it will be very
>>>>> close to any kind of IDL that will be supported in the future; the ROS
>>>>> "IDL" being the first one. Maybe adding two prefixes would be most
>>>>> flexible: - one to make the distinction between an abstract _model_ of
>>>>> the messages This could be the "I", or the "M" standing for "meta",
>>>>> "model". - one to indicate the "model context", such as CORBA, ROS,...
>>>>> With "C", "R",... as appropriate prefixes (I prefer to use more than one
>>>>> letter to indicate the model context...)
>>>>>
>>>> And what about we actually solve actual problems instead of
>>>> over-engineering RTT (even more that it was in 1.x) ? If you want to do
>>>> meta-modelling, then -- anyway -- you will do it in a meta-model
>>>> language and will be able to remove any prefix there, so why bother
>>>> overloading the RTT's CORBA IDL with whatever might or might not happen ?
>>>>
>>>> CORBA IDL *is* CORBA IDL. It is not a meta-modelling language, it is a
>>>> CORBA-specific definition language.
>>>>
>>> Yes, but RTT already gives way too much the impression that it is tied to
>>> CORBA! And that is a significant part of the "overengineering" that you
>>> mention (and that I agree with): 1.x was very influenced by CORBA, and we
>>> now pay the price for that...
>>>
>>> I think we should get CORBA _completely_ out of sight in RTT, and move it
>>> to a new kind of Orocos-subproject ("middleware bindings" or something like
>>> that). If we keep it in the RTT scope, anything that is added to RTT should
>>> be CORBA independent, hence my suggestion to introduce a "meta model"
>>> description, of which the CORBA IDL would just be a concrete instantiation.
>>>
>>
>> The IDL we are talking about is part of the corba transport and would be moved
>> out of RTT as well then. It is 'the interface of the corba transport'. Our
>> conceptual model of an RTT component is what is being developed at
>> Leuven/Brics right now :-)
>>
> Since everyone in the thread agrees, I updated the merge request ...
Oops... since when do we reach concensus _that_ quickly!?!?! :-)
Herman