On Wed, 20 Apr 2011, Sylvain Joyeux wrote:

> On 04/20/2011 05:58 PM, Stephen Roderick wrote:
>> On Apr 20, 2011, at 11:35 , Sylvain Joyeux wrote:
>>
>>> On 04/20/2011 05:12 PM, Stephen Roderick wrote:
>>>> So an activity that isn't coupled to a component ... ok. But won't you end up encoding in that entity (somehow) the execution order you are interested in? For more than the most trivial cases, isn't that heading back in the direction of a statemachine ... which leads to a component ... which puts you back where we are now?
>>> Yes, in general, I can implement my use case in a state machine in a coordination component. Now, as always, it is also a matter of reusability (there are quite a few use cases for something like that) and I personally feel that it is more part of the "activity" semantic than of the "component" semantic.
>>>
>>> Moreover, using a component for that has the drawback that the underlying components become dependent on this coordination component, i.e. you can't run them separately anymore (i.e. you can't start/stop them separately). I'm not saying it is bad, but it's something I'd like to avoid.
>>
>> I don't get this bit. The component implementation isn't affected by its use by a Coordinator component, so I presume you are referring to being unable to use the component in both a master/slave activity, as well as using it separately in some other manner (ie being able to independantly start/stop it)? If so, then we run into this sometimes. Sometimes we want the same component to be slave to one master at one time, and slave to another master at a different time.
> When you say "different times", do you mean "during the same execution"
> or "in different executions" ?
>
> To repeat myself (because these days I have an even harder time making
> myself clear, apologies for that). I don't think there is a fundamental
> problem with the Coordinator component approach. It's just that it does
> not fit the way we deploy systems right now, as you don't start/stop a
> component by calling start/stop on it anymore, but by *first* starting a
> "scheduling" component and *then* calling start/stop on it.
>
> In principle, it is something I can encode in our supervision layer,
> it's just that I feel it is adding more complexity to the system for no
> added value, in the case where a simple "scheduling-like" activity is
> enough. I.e. I would rather keep it at the activity level than at the
> level of a full-blown component.

My two cents... The "activity level" is concerned with the _physical
resources_ that your application is using, and should indeed be decoupled
from the _application_-level component Coordination. Nevertheless, also the
physical resources require Coordination; this Coordination, however, could
be done outside of the Orocos/RTT context, with other means. But it
_remains_ Coordination :-) (I sometimes call it the "Container" part of the
component model.)

>>>> Also, I don't get what you mean with "integral number of times the master period". Are you trying to schedule components to not run every cycle of the master, or is this your intended way to cycle between multiple components (e.g set A on every 4th cycle from 1 = 1,5,9, B every 4th from 2 = 2,6,10, etc leading to a sequence of A,B,C,D,A,B,C,D on cycles of the master)?
>>> I have the feeling that the second option you are offering is a more general case of the first. So let's say I would go for the second option.
>>
>> I wasn't actually suggesting the second option, I was trying to understand what you were proposing. I wouldn't personally suggest that this option ...
> Miswording from my part. I got your idea.
>
>>> Here's the thing: it is "a pattern". That you put this pattern in a component or in an activity class does not really matter, as it is meant to be used as-is (i.e. configured and then running transparently). I just want
>>>
>>> * an implementation of a scheme like this
>>> * extend the orogen deployment spec to make this scheme easily usable
>>>
>>> I was asking on the ML as I was wondering if such a patter already existed or not. It seems not ;-)
>>
>> Some of what you're talking about overlaps with issues we have, so I'm just trying to better understand what you're thinking of adding to RTT, in case we'd like to help out or slightly modify the approach.
> Having a solution that fit all our needs would be good indeed :P

Herman