Hello.
I would like to purpose a "new" Service Architecture.
The current patch (attached file) add a ServiceInterface base class that inherit the three interfaces (DataFlow, Configuration, and Operation). The Service and ServiceRequester inherit the ServiceInterface.
No new features are implemented, it should do the same thing than before.
The patch compile, but before going further, i would like to have your opinion : is it acceptable ?
The next things i would like to do is to rename Service in ServiceProvider, ServiceInterface in Service.
Then i will try to update the transport implementation to take into account the Service base class.
Next i will try to reimplement connectTo to be able to connect ports, configurations and operations.
Could you give me some advices please ?
Paul.
| Attachment | Size |
|---|---|
| 0001-New-service-architecture.patch | 49.7 KB |
[PATCH] New Services architecture.
On Sunday 21 November 2010 15:36:00 paul [dot] chavent [..] ... wrote:
> Hello.
>
> I would like to purpose a "new" Service Architecture.
>
> The current patch (attached file) add a ServiceInterface base class that
> inherit the three interfaces (DataFlow, Configuration, and Operation). The
> Service and ServiceRequester inherit the ServiceInterface.
>
> No new features are implemented, it should do the same thing than before.
>
> The patch compile, but before going further, i would like to have your
> opinion : is it acceptable ?
>
> The next things i would like to do is to rename Service in ServiceProvider,
> ServiceInterface in Service.
>
> Then i will try to update the transport implementation to take into account
> the Service base class.
>
> Next i will try to reimplement connectTo to be able to connect ports,
> configurations and operations.
>
> Could you give me some advices please ?
The first important issue is that we won't do any renames of classes in the
RTT:: namespace. It's just not an option for the next year(s). So please keep
that in mind. We can add classes though, preferably in the sub-namespaces of
'RTT'.
I've had a sneak-preview to the document you created of your use case, and it
got me worried. The amount of code we need to setup two or three components is
daunting. The whole idea should be that writing components is 'cheap' and as
such setting up an object-interface framework of implementations behind a
single component shouldn't be a thing you want to do. I'm pointing at a
problem with the RTT, not at a problem in your design. In a way, you're
reproducing in C++ what orogen is generating for you (partly, because orogen
only does data flow ports and not services!). If you already have an interface
you want to provide/require, why don't we extend one of these code generators
to generate that code for you ?
I don't claim that the current serviceprovider/requester scheme works/looks
good. I certainly welcome improvements. But this is not something we will
merge on master in the coming months.
Peter
[PATCH] New Services architecture.
Hello Peter
Peter Soetens wrote:
> On Sunday 21 November 2010 15:36:00 paul [dot] chavent [..] ... wrote:
>> Hello.
>>
>> I would like to purpose a "new" Service Architecture.
>>
>> The current patch (attached file) add a ServiceInterface base class that
>> inherit the three interfaces (DataFlow, Configuration, and Operation). The
>> Service and ServiceRequester inherit the ServiceInterface.
>>
>> No new features are implemented, it should do the same thing than before.
>>
>> The patch compile, but before going further, i would like to have your
>> opinion : is it acceptable ?
>>
>> The next things i would like to do is to rename Service in ServiceProvider,
>> ServiceInterface in Service.
>>
>> Then i will try to update the transport implementation to take into account
>> the Service base class.
>>
>> Next i will try to reimplement connectTo to be able to connect ports,
>> configurations and operations.
>>
>> Could you give me some advices please ?
>
> The first important issue is that we won't do any renames of classes in the
> RTT:: namespace. It's just not an option for the next year(s). So please keep
> that in mind. We can add classes though, preferably in the sub-namespaces of
> 'RTT'.
That's not an issue. I will keep the current naming convention.
>
> I've had a sneak-preview to the document you created of your use case, and it
Yes there has been a problem with the size of the message, so, for the document, see here http://paul.chavent.free.fr/orocos/Camera.pdf
> got me worried. The amount of code we need to setup two or three components is
> daunting. The whole idea should be that writing components is 'cheap' and as
> such setting up an object-interface framework of implementations behind a
> single component shouldn't be a thing you want to do. I'm pointing at a
> problem with the RTT, not at a problem in your design. In a way, you're
> reproducing in C++ what orogen is generating for you (partly, because orogen
> only does data flow ports and not services!).
I'am a bit afraid if you tell me that we should use orogen to generate boring code, in order to balance a lack of programming features for humans.
Orogen should avoid the programming of recurrent patterns, not allow to generate workarounds.
> If you already have an interface
> you want to provide/require, why don't we extend one of these code generators
> to generate that code for you ?
I'am not very familiar with orogen, and i don't want to use code generator for now.
But i prefer to improve the API instead of making black magic with code generation.
>
>
> I don't claim that the current serviceprovider/requester scheme works/looks
> good. I certainly welcome improvements. But this is not something we will
> merge on master in the coming months.
>
OK. So, i will use my patch for personal use and inform you of its evolution (and there will certainly...).
> Peter
Thank you for your review.
Paul.
[PATCH] New Services architecture.
On Mon, 22 Nov 2010, Paul Chavent wrote:
> Hello Peter
>
> Peter Soetens wrote:
>> On Sunday 21 November 2010 15:36:00 paul [dot] chavent [..] ... wrote:
>>> Hello.
>>>
>>> I would like to purpose a "new" Service Architecture.
>>>
>>> The current patch (attached file) add a ServiceInterface base class that
>>> inherit the three interfaces (DataFlow, Configuration, and Operation). The
>>> Service and ServiceRequester inherit the ServiceInterface.
>>>
>>> No new features are implemented, it should do the same thing than before.
>>>
>>> The patch compile, but before going further, i would like to have your
>>> opinion : is it acceptable ?
>>>
>>> The next things i would like to do is to rename Service in ServiceProvider,
>>> ServiceInterface in Service.
>>>
>>> Then i will try to update the transport implementation to take into account
>>> the Service base class.
>>>
>>> Next i will try to reimplement connectTo to be able to connect ports,
>>> configurations and operations.
>>>
>>> Could you give me some advices please ?
>>
>> The first important issue is that we won't do any renames of classes in the
>> RTT:: namespace. It's just not an option for the next year(s). So please keep
>> that in mind. We can add classes though, preferably in the sub-namespaces of
>> 'RTT'.
>
> That's not an issue. I will keep the current naming convention.
>
>>
>> I've had a sneak-preview to the document you created of your use case, and it
>
> Yes there has been a problem with the size of the message, so, for the document, see here http://paul.chavent.free.fr/orocos/Camera.pdf
>
>> got me worried. The amount of code we need to setup two or three components is
>> daunting. The whole idea should be that writing components is 'cheap' and as
>> such setting up an object-interface framework of implementations behind a
>> single component shouldn't be a thing you want to do. I'm pointing at a
>> problem with the RTT, not at a problem in your design. In a way, you're
>> reproducing in C++ what orogen is generating for you (partly, because orogen
>> only does data flow ports and not services!).
>
> I'am a bit afraid if you tell me that we should use orogen to generate boring code, in order to balance a lack of programming features for humans.
>
> Orogen should avoid the programming of recurrent patterns, not allow to generate workarounds.
>
>> If you already have an interface
>> you want to provide/require, why don't we extend one of these code generators
>> to generate that code for you ?
>
> I'am not very familiar with orogen, and i don't want to use code generator for now.
> But i prefer to improve the API instead of making black magic with code generation.
>
There is no reason why code generation should be "black magic"... On the
contrary: if there is a well-defined and understood "model" to generate the
code from, code generation can be a dream to have.
>> I don't claim that the current serviceprovider/requester scheme works/looks
>> good. I certainly welcome improvements. But this is not something we will
>> merge on master in the coming months.
>
> OK. So, i will use my patch for personal use and inform you of its
> evolution (and there will certainly...).
Good luck!
>> Peter
>
> Thank you for your review.
>
> Paul.
Herman
[PATCH] New Services
contrary: if there is a well-defined and understood "model" to generate the
code from, code generation can be a dream to have.
I agree with that. I agree with Peter that tell me to use code generation for my use case.
But i don't know how to implement my model with the current API. So i don't know which code orogen could generate for doing the job.
Thank you :)
[PATCH] New Services architecture.
I agree with that. I agree with Peter that tell me to use code generation for my use case.
But i don't know how to implement my model with the current API. So i don't know which code orogen could generate for doing the job.
Thank you :)
[PATCH] New Services
On Tue, 23 Nov 2010, paul [dot] chavent [..] ... wrote:
>
> contrary: if there is a well-defined and understood "model" to generate the
> code from, code generation can be a dream to have.
>
> I agree with that. I agree with Peter that tell me to use code generation for my use case.
>
> But i don't know how to implement my model with the current API.
You are putting your finger on one of the weak points of our current code
base: it is not yet ready to support code generation :-( The first steps in
this direction are being set:
- definition of a "component model", that separates Computation,
Communication, Configuration and Coordination, such that appropriate
models and APIs can be refactored to better support code generation.
- making "Eclipse ecore" models for all of the above, in the hope that
we can profit from the large efforts around code generation (and other
useful tools) that the Eclipse ecosystem is providing.
Both efforts are significantly supported by the BRICS project, but will
take another six months or so before we can expect the first visible
results.
> So i don't know which code orogen could generate for doing the job.
>
>
>
> Thank you :)
Maybe we can try to do something together to reduce our dependency on luck :-)
I mean, if you have some ideas how we should proceed towards this goal,
please feel free to post them for discussion on this list... The effort
will not lead to usable results within less than six months or so.
Herman
[PATCH] New Services
The first steps in
this direction are being set:
- definition of a "component model", that separates Computation,
Communication, Configuration and Coordination, such that appropriate
models and APIs can be refactored to better support code generation.
- making "Eclipse ecore" models for all of the above, in the hope that
we can profit from the large efforts around code generation (and other
useful tools) that the Eclipse ecosystem is providing.
...
Both efforts are significantly supported by the BRICS project
You seems to have some lenght of advance on this topic. I will try to read some documentation.
Maybe we can try to do something together to reduce our dependency on luck :-)
I mean, if you have some ideas how we should proceed towards this goal,
please feel free to post them for discussion on this list... The effort
will not lead to usable results within less than six months or so.
I'am not hurry.
I would like to be involved in the debate of the definition of a "component model".
So... we will meet again ! Ha Ha Ha Ha Ha :)
Re: [PATCH] New Services
You seems to have some lenght of advance on this topic. I will try to read some documentation.
I'am not hurry.
I would like to be involved in the debate of the definition of a "component model".
So... we will meet again ! Ha Ha Ha Ha Ha :)
[PATCH] New Services
Hello Paul,
>
> The first steps in
> this direction are being set:
> - definition of a "component model", that separates Computation,
> Communication, Configuration and Coordination, such that appropriate
> models and APIs can be refactored to better support code generation.
> - making "Eclipse ecore" models for all of the above, in the hope that
> we can profit from the large efforts around code generation (and other
> useful tools) that the Eclipse ecosystem is providing.
> ...
> Both efforts are significantly supported by the BRICS project
>
>
> You seems to have some lenght of advance on this topic. I will try to read some documentation.
>
>
> Maybe we can try to do something together to reduce our dependency on luck :-)
> I mean, if you have some ideas how we should proceed towards this goal,
> please feel free to post them for discussion on this list... The effort
> will not lead to usable results within less than six months or so.
>
>
> I'am not hurry.
>
> I would like to be involved in the debate of the definition of a "component model".
During the last months we had some very intensive discussions on
that topic. One outcome is the decision to separate the structural
and behavioral part of components also on the "model level".
The current model includes basically an explicit representation of
Components, Composites, Connections, Services, and Properties.
Those primitives are used to achieve the separation of concerns which
Herman mentioned (e.g. separation of the Configuration through
properties), and are found in other well-known component-based frameworks.
It will take more time to materialize the ideas into running code. But,
we should be very soon ready to publish the core ideas in a more
elaborated manner. Stay tuned!
Nico
>
> So... we will meet again ! Ha Ha Ha Ha Ha :)
>
[PATCH] New Services
On Tue, 23 Nov 2010, Nico Hochgeschwender wrote:
>
>
> Hello Paul,
>
>>
>> The first steps in
>> this direction are being set:
>> - definition of a "component model", that separates Computation,
>> Communication, Configuration and Coordination, such that appropriate
>> models and APIs can be refactored to better support code generation.
>> - making "Eclipse ecore" models for all of the above, in the hope that
>> we can profit from the large efforts around code generation (and other
>> useful tools) that the Eclipse ecosystem is providing.
>> ...
>> Both efforts are significantly supported by the BRICS project
>>
>>
>> You seems to have some lenght of advance on this topic. I will try to read some documentation.
>>
>>
>> Maybe we can try to do something together to reduce our dependency on luck :-)
>> I mean, if you have some ideas how we should proceed towards this goal,
>> please feel free to post them for discussion on this list... The effort
>> will not lead to usable results within less than six months or so.
>>
>>
>> I'am not hurry.
>>
>> I would like to be involved in the debate of the definition of a "component model".
>
> During the last months we had some very intensive discussions on
> that topic. One outcome is the decision to separate the structural
> and behavioral part of components also on the "model level".
>
> The current model includes basically an explicit representation of
> Components, Composites, Connections, Services, and Properties.
Which is the "SCA" model mentioned in my previous post.
> Those primitives are used to achieve the separation of concerns which
> Herman mentioned (e.g. separation of the Configuration through
> properties), and are found in other well-known component-based frameworks.
>
> It will take more time to materialize the ideas into running code. But,
> we should be very soon ready to publish the core ideas in a more
> elaborated manner. Stay tuned!
>
> Nico
>
>>
>> So... we will meet again ! Ha Ha Ha Ha Ha :)
FYI: Nico is the "task force leader" of this activity in the BRICS project.
Herman