I hide under rocks... with PJ.

The "latter" discussion was
http://www.orocos.org/forum/orocos/orocos-users/deployment-methods-service

I still think it would be usefull for some components to be abble to deply
other dynamically outside the Deployer, for example in an hardware
Component that would receive "bootups" and launch components to handle the
hardware without "a priori" knowledge of what will be plugged. Anyway I
understood that those deployer issue is the visible part of the iceberg
"deploying workflow"

2012/1/7 Willy Lambert <lambert [dot] willy [..] ...>

> Hi all,
>
> I am always ambarrassed by the list of peer of the deployer which is
> growing fast with the growing of the project. What's missing behind this is
> the lack of composite component.
> The latter discussion about using deployers in deployer was in a way to
> solve this (and also the deployer's file organization which can be done
> without this anyway).
>
> I find another way to go that also solve my Monitoring problem. As my
> application is clustered into several groups (like hardware, movement,
> localization), I wanted to have Supervisors that could say "this group if
> working fine rigth know" to other groups (this is important since
> developpers of the different groups are different, so they need as clean
> and ligth interfacs as possible).
>
> I also had problems with putting the configure/start of component in the
> deployer since all components don't need to be working at every time. And
> more, I wanted a way to reset groups of components.
>
> Here is what I did :
> _ I created a Monitoring component that is responsible to
> configure/start/stop/cleanup all its registered peers.
> _ The Monitoring Component watch its registered peers during updateHook
> and goes into Error state if one is not healthy
> _ I register components of the group in the Monitor
> _ I remove the peer from the Deployer.
>
> So my top TaskBrowser view is only containing several monitors that hide
> plenty of components. To be aware of my application health I just have to
> check the health of those monitors (becaus ethey encapsulate the health of
> the sub components).
>
> Is there anything wrong doing this ?
>
> I joined my Monitor component. It is dependent of my personnal framework
> because it inherits from ARDTaskContext but there is nothing required for
> this, so one can remove those dependencies to be a pure Orocos component.As
> this is a recurrent problem (sharing your code when your inherit from a
> personnal FatherTaskContext), doest it means that this kind of functionnal
> code should be encapsulated in a service ?
>