[RFC] Component Deployment and scripting in 2.2

We're looking at improving deployment of components, and now's a good time to
give your feedback. These features will be developed after 2.1 is released.

Most users are not happy with the XML format that specifies which components
are loaded and connected in an application. Especially the flexibility and the
fixed ordering of configuration/setup steps disturbs even modest applications.
The scripting interface on the other hand provides a more controlled, readable
and flexible environment to specify how an application must be setup.

Therefor, the 'best practice' in deployment will emphasis doing things in
scripts and leave XML for basic setup steps. For example: importing component
libraries or plugins and instantiating components. Everything after that
should be done in a script.

For this to work as painless as possible, we need to relook at the scripting
API of the DeploymentComponent and how XML and scripting integrate better.
These features would be 'primary' for the XML:

* Loading plugins, component libraries etc. -- 'Import'
* Instantiating components -- component struct

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter

[RFC] Component Deployment and scripting in 2.2

On Saturday 16 October 2010 18:46:34 Stephen Roderick wrote:
> On Oct 16, 2010, at 10:08 , Peter Soetens wrote:
> > On Thu, Sep 30, 2010 at 2:37 PM, Stephen Roderick <kiwi [dot] net [..] ...>
wrote:
> >> On Sep 30, 2010, at 08:27 , Peter Soetens wrote:
> >>> On Thursday 30 September 2010 14:09:34 S Roderick wrote:
> >>>> On Sep 30, 2010, at 07:45 , Peter Soetens wrote:
> >>>>> We're looking at improving deployment of components, and now's a good
> >>>>> time to give your feedback. These features will be developed after
> >>>>> 2.1 is released.
> >>>>
> >>>> Add the ability to deploy components in groups, so that group A is
> >>>> deployed completely, followed by group B, ..., and then group B is
> >>>> un-deployed completely, and finally group A is un-deployed
> >>>> completely. This is necessary for things like logging, which
> >>>> currently hacks this by using the site-file approach. This is really
> >>>> just sequencing application startup and shutdown.
> >>>
> >>> You *can* already do this using scripting and a state machine.That's my
> >>> whole point. No XML / DeploymentComponent extensions are necessary for
> >>> this.
> >>
> >> Got an example?
> >
> > On how to do that ? With one XML file and one script:
> >
> > Which components to load:
> > &#10;&gt; &gt; &lt;properties&gt;&#10;&gt; &gt; &lt;struct name=&quot;A1&quot; type=&quot;XType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;A2&quot; type=&quot;YType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B1&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;struct name=&quot;B2&quot; type=&quot;ZType&quot; /&gt;&#10;&gt; &gt; &lt;/properties&gt;&#10;&gt; &gt;
> >
> > How to configure them (1.x compatible syntax)
> > &#10;&gt; &gt; StateMachine SetupShutdown {&#10;&gt; &gt; &#10;&gt; &gt;    var bool do_cleanup = false;&#10;&gt; &gt;    initial state setup {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Configure A group&#10;&gt; &gt;                do A1.configure() ; do A2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;A1&quot;,&quot;Port1&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do A1.start() ; do A2.start();&#10;&gt; &gt;                &#10;&gt; &gt;                // Configure B group&#10;&gt; &gt;                do B1.configure() ; do B2.configure();&#10;&gt; &gt;                do connectTwoPorts(&quot;B1&quot;,&quot;PortBar&quot;, &quot;A2&quot;,&quot;PortFoo&quot;);&#10;&gt; &gt;                do B1.start() ; do B2.start();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;           transitions { if do_cleanup then select shutdown; }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt;    &#10;&gt; &gt;    final state shutdown {&#10;&gt; &gt;    &#10;&gt; &gt;           entry {&#10;&gt; &gt;           &#10;&gt; &gt;                // Cleanup B group&#10;&gt; &gt;                do B1.stop() ; do B2.stop();&#10;&gt; &gt;                do B1.cleanup() ; do B2.cleanup();&#10;&gt; &gt;                &#10;&gt; &gt;                // Cleanup A group&#10;&gt; &gt;                do A1.stop() ; do A2.stop();&#10;&gt; &gt;                do A1.cleanup() ; do A2.cleanup();&#10;&gt; &gt;           &#10;&gt; &gt;           }&#10;&gt; &gt;    &#10;&gt; &gt;    }&#10;&gt; &gt; &#10;&gt; &gt; }&#10;&gt; &gt; RootMachine SetupShutdown deploygroups;&#10;&gt; &gt;
> >
> > The limitation of scripting is that components must be loaded before the
> > script is *parsed*, so that's why I declare them in XML first, and do all
> > the rest in a script.
>
> Interesting approach. One benefit of XML that I don't immediately see a way
> to do above, is that you can compose a system very easily from multiple
> XML files. If I wanted to have a scenario as above with the A and B
> groups, and another scenario with A, B, and C groups, I'd need two files
> duplicating the A and B parts. With XML or grouped loading, I can feed the
> deployer the group A file, then the B file, then the C file.

I don't see why you couldn't do this in scripting ? Isn't it just three state
machines, one for group A, one for B and one for C ? I conveniently had A and
B in the same SM above, but that is separatable. What you do gain is the
implicit ordering of the loading/unloading groups: the later an xml is loaded,
the earlier it is unloaded again. We could(should?) have the same policy for
stopping the state machines, ie stop latest loaded first.

My poposal will in fact allow to coordinate this much better, by allowing 'top
level' coordinative instructions in your script files, ie, directly starting a
state machine etc. Exactly the same arguments are true for the lua scripting,
where XML is entirely unnecessary, since you can create and use components
directly in one script.

What we can't do is 'xacro'-like preprocessing since the scripting is not
providing any preprocessing tools. xacro is a ros extension which is getting
quite popular.

Peter