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:
> >

> > <properties>
> > <struct name="A1" type="XType" />
> > <struct name="A2" type="YType" />
> > <struct name="B1" type="ZType" />
> > <struct name="B2" type="ZType" />
> > </properties>
> > 

> > StateMachine SetupShutdown {
> > 
> >    var bool do_cleanup = false;
> >    initial state setup {
> >    
> >           entry {
> >           
> >                // Configure A group
> >                do A1.configure() ; do A2.configure();
> >                do connectTwoPorts("A1","Port1", "A2","PortFoo");
> >                do A1.start() ; do A2.start();
> >                
> >                // Configure B group
> >                do B1.configure() ; do B2.configure();
> >                do connectTwoPorts("B1","PortBar", "A2","PortFoo");
> >                do B1.start() ; do B2.start();
> >           
> >           }
> >           transitions { if do_cleanup then select shutdown; }
> >    
> >    }
> >    
> >    final state shutdown {
> >    
> >           entry {
> >           
> >                // Cleanup B group
> >                do B1.stop() ; do B2.stop();
> >                do B1.cleanup() ; do B2.cleanup();
> >                
> >                // Cleanup A group
> >                do A1.stop() ; do A2.stop();
> >                do A1.cleanup() ; do A2.cleanup();
> >           
> >           }
> >    
> >    }
> > 
> > }
> > RootMachine SetupShutdown deploygroups;
> > 

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

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:
> >

> > <properties>
> > <struct name="A1" type="XType" />
> > <struct name="A2" type="YType" />
> > <struct name="B1" type="ZType" />
> > <struct name="B2" type="ZType" />
> > </properties>
> > 

> > StateMachine SetupShutdown {
> > 
> >    var bool do_cleanup = false;
> >    initial state setup {
> >    
> >           entry {
> >           
> >                // Configure A group
> >                do A1.configure() ; do A2.configure();
> >                do connectTwoPorts("A1","Port1", "A2","PortFoo");
> >                do A1.start() ; do A2.start();
> >                
> >                // Configure B group
> >                do B1.configure() ; do B2.configure();
> >                do connectTwoPorts("B1","PortBar", "A2","PortFoo");
> >                do B1.start() ; do B2.start();
> >           
> >           }
> >           transitions { if do_cleanup then select shutdown; }
> >    
> >    }
> >    
> >    final state shutdown {
> >    
> >           entry {
> >           
> >                // Cleanup B group
> >                do B1.stop() ; do B2.stop();
> >                do B1.cleanup() ; do B2.cleanup();
> >                
> >                // Cleanup A group
> >                do A1.stop() ; do A2.stop();
> >                do A1.cleanup() ; do A2.cleanup();
> >           
> >           }
> >    
> >    }
> > 
> > }
> > RootMachine SetupShutdown deploygroups;
> > 

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

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:
> >

> > <properties>
> > <struct name="A1" type="XType" />
> > <struct name="A2" type="YType" />
> > <struct name="B1" type="ZType" />
> > <struct name="B2" type="ZType" />
> > </properties>
> > 

> > StateMachine SetupShutdown {
> > 
> >    var bool do_cleanup = false;
> >    initial state setup {
> >    
> >           entry {
> >           
> >                // Configure A group
> >                do A1.configure() ; do A2.configure();
> >                do connectTwoPorts("A1","Port1", "A2","PortFoo");
> >                do A1.start() ; do A2.start();
> >                
> >                // Configure B group
> >                do B1.configure() ; do B2.configure();
> >                do connectTwoPorts("B1","PortBar", "A2","PortFoo");
> >                do B1.start() ; do B2.start();
> >           
> >           }
> >           transitions { if do_cleanup then select shutdown; }
> >    
> >    }
> >    
> >    final state shutdown {
> >    
> >           entry {
> >           
> >                // Cleanup B group
> >                do B1.stop() ; do B2.stop();
> >                do B1.cleanup() ; do B2.cleanup();
> >                
> >                // Cleanup A group
> >                do A1.stop() ; do A2.stop();
> >                do A1.cleanup() ; do A2.cleanup();
> >           
> >           }
> >    
> >    }
> > 
> > }
> > RootMachine SetupShutdown deploygroups;
> > 

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

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:
> >

> > <properties>
> > <struct name="A1" type="XType" />
> > <struct name="A2" type="YType" />
> > <struct name="B1" type="ZType" />
> > <struct name="B2" type="ZType" />
> > </properties>
> > 

> > StateMachine SetupShutdown {
> > 
> >    var bool do_cleanup = false;
> >    initial state setup {
> >    
> >           entry {
> >           
> >                // Configure A group
> >                do A1.configure() ; do A2.configure();
> >                do connectTwoPorts("A1","Port1", "A2","PortFoo");
> >                do A1.start() ; do A2.start();
> >                
> >                // Configure B group
> >                do B1.configure() ; do B2.configure();
> >                do connectTwoPorts("B1","PortBar", "A2","PortFoo");
> >                do B1.start() ; do B2.start();
> >           
> >           }
> >           transitions { if do_cleanup then select shutdown; }
> >    
> >    }
> >    
> >    final state shutdown {
> >    
> >           entry {
> >           
> >                // Cleanup B group
> >                do B1.stop() ; do B2.stop();
> >                do B1.cleanup() ; do B2.cleanup();
> >                
> >                // Cleanup A group
> >                do A1.stop() ; do A2.stop();
> >                do A1.cleanup() ; do A2.cleanup();
> >           
> >           }
> >    
> >    }
> > 
> > }
> > RootMachine SetupShutdown deploygroups;
> > 

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

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:
> >

> > <properties>
> > <struct name="A1" type="XType" />
> > <struct name="A2" type="YType" />
> > <struct name="B1" type="ZType" />
> > <struct name="B2" type="ZType" />
> > </properties>
> > 

> > StateMachine SetupShutdown {
> > 
> >    var bool do_cleanup = false;
> >    initial state setup {
> >    
> >           entry {
> >           
> >                // Configure A group
> >                do A1.configure() ; do A2.configure();
> >                do connectTwoPorts("A1","Port1", "A2","PortFoo");
> >                do A1.start() ; do A2.start();
> >                
> >                // Configure B group
> >                do B1.configure() ; do B2.configure();
> >                do connectTwoPorts("B1","PortBar", "A2","PortFoo");
> >                do B1.start() ; do B2.start();
> >           
> >           }
> >           transitions { if do_cleanup then select shutdown; }
> >    
> >    }
> >    
> >    final state shutdown {
> >    
> >           entry {
> >           
> >                // Cleanup B group
> >                do B1.stop() ; do B2.stop();
> >                do B1.cleanup() ; do B2.cleanup();
> >                
> >                // Cleanup A group
> >                do A1.stop() ; do A2.stop();
> >                do A1.cleanup() ; do A2.cleanup();
> >           
> >           }
> >    
> >    }
> > 
> > }
> > RootMachine SetupShutdown deploygroups;
> > 

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

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:
> >

> > <properties>
> > <struct name="A1" type="XType" />
> > <struct name="A2" type="YType" />
> > <struct name="B1" type="ZType" />
> > <struct name="B2" type="ZType" />
> > </properties>
> > 

> > StateMachine SetupShutdown {
> > 
> >    var bool do_cleanup = false;
> >    initial state setup {
> >    
> >           entry {
> >           
> >                // Configure A group
> >                do A1.configure() ; do A2.configure();
> >                do connectTwoPorts("A1","Port1", "A2","PortFoo");
> >                do A1.start() ; do A2.start();
> >                
> >                // Configure B group
> >                do B1.configure() ; do B2.configure();
> >                do connectTwoPorts("B1","PortBar", "A2","PortFoo");
> >                do B1.start() ; do B2.start();
> >           
> >           }
> >           transitions { if do_cleanup then select shutdown; }
> >    
> >    }
> >    
> >    final state shutdown {
> >    
> >           entry {
> >           
> >                // Cleanup B group
> >                do B1.stop() ; do B2.stop();
> >                do B1.cleanup() ; do B2.cleanup();
> >                
> >                // Cleanup A group
> >                do A1.stop() ; do A2.stop();
> >                do A1.cleanup() ; do A2.cleanup();
> >           
> >           }
> >    
> >    }
> > 
> > }
> > RootMachine SetupShutdown deploygroups;
> > 

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

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:
> >

> > <properties>
> > <struct name="A1" type="XType" />
> > <struct name="A2" type="YType" />
> > <struct name="B1" type="ZType" />
> > <struct name="B2" type="ZType" />
> > </properties>
> > 

> > StateMachine SetupShutdown {
> > 
> >    var bool do_cleanup = false;
> >    initial state setup {
> >    
> >           entry {
> >           
> >                // Configure A group
> >                do A1.configure() ; do A2.configure();
> >                do connectTwoPorts("A1","Port1", "A2","PortFoo");
> >                do A1.start() ; do A2.start();
> >                
> >                // Configure B group
> >                do B1.configure() ; do B2.configure();
> >                do connectTwoPorts("B1","PortBar", "A2","PortFoo");
> >                do B1.start() ; do B2.start();
> >           
> >           }
> >           transitions { if do_cleanup then select shutdown; }
> >    
> >    }
> >    
> >    final state shutdown {
> >    
> >           entry {
> >           
> >                // Cleanup B group
> >                do B1.stop() ; do B2.stop();
> >                do B1.cleanup() ; do B2.cleanup();
> >                
> >                // Cleanup A group
> >                do A1.stop() ; do A2.stop();
> >                do A1.cleanup() ; do A2.cleanup();
> >           
> >           }
> >    
> >    }
> > 
> > }
> > RootMachine SetupShutdown deploygroups;
> > 

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

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:
> >

> > <properties>
> > <struct name="A1" type="XType" />
> > <struct name="A2" type="YType" />
> > <struct name="B1" type="ZType" />
> > <struct name="B2" type="ZType" />
> > </properties>
> > 

> > StateMachine SetupShutdown {
> > 
> >    var bool do_cleanup = false;
> >    initial state setup {
> >    
> >           entry {
> >           
> >                // Configure A group
> >                do A1.configure() ; do A2.configure();
> >                do connectTwoPorts("A1","Port1", "A2","PortFoo");
> >                do A1.start() ; do A2.start();
> >                
> >                // Configure B group
> >                do B1.configure() ; do B2.configure();
> >                do connectTwoPorts("B1","PortBar", "A2","PortFoo");
> >                do B1.start() ; do B2.start();
> >           
> >           }
> >           transitions { if do_cleanup then select shutdown; }
> >    
> >    }
> >    
> >    final state shutdown {
> >    
> >           entry {
> >           
> >                // Cleanup B group
> >                do B1.stop() ; do B2.stop();
> >                do B1.cleanup() ; do B2.cleanup();
> >                
> >                // Cleanup A group
> >                do A1.stop() ; do A2.stop();
> >                do A1.cleanup() ; do A2.cleanup();
> >           
> >           }
> >    
> >    }
> > 
> > }
> > RootMachine SetupShutdown deploygroups;
> > 

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

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:
> >

> > <properties>
> > <struct name="A1" type="XType" />
> > <struct name="A2" type="YType" />
> > <struct name="B1" type="ZType" />
> > <struct name="B2" type="ZType" />
> > </properties>
> > 

> > StateMachine SetupShutdown {
> > 
> >    var bool do_cleanup = false;
> >    initial state setup {
> >    
> >           entry {
> >           
> >                // Configure A group
> >                do A1.configure() ; do A2.configure();
> >                do connectTwoPorts("A1","Port1", "A2","PortFoo");
> >                do A1.start() ; do A2.start();
> >                
> >                // Configure B group
> >                do B1.configure() ; do B2.configure();
> >                do connectTwoPorts("B1","PortBar", "A2","PortFoo");
> >                do B1.start() ; do B2.start();
> >           
> >           }
> >           transitions { if do_cleanup then select shutdown; }
> >    
> >    }
> >    
> >    final state shutdown {
> >    
> >           entry {
> >           
> >                // Cleanup B group
> >                do B1.stop() ; do B2.stop();
> >                do B1.cleanup() ; do B2.cleanup();
> >                
> >                // Cleanup A group
> >                do A1.stop() ; do A2.stop();
> >                do A1.cleanup() ; do A2.cleanup();
> >           
> >           }
> >    
> >    }
> > 
> > }
> > RootMachine SetupShutdown deploygroups;
> > 

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

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:
> >

> > <properties>
> > <struct name="A1" type="XType" />
> > <struct name="A2" type="YType" />
> > <struct name="B1" type="ZType" />
> > <struct name="B2" type="ZType" />
> > </properties>
> > 

> > StateMachine SetupShutdown {
> > 
> >    var bool do_cleanup = false;
> >    initial state setup {
> >    
> >           entry {
> >           
> >                // Configure A group
> >                do A1.configure() ; do A2.configure();
> >                do connectTwoPorts("A1","Port1", "A2","PortFoo");
> >                do A1.start() ; do A2.start();
> >                
> >                // Configure B group
> >                do B1.configure() ; do B2.configure();
> >                do connectTwoPorts("B1","PortBar", "A2","PortFoo");
> >                do B1.start() ; do B2.start();
> >           
> >           }
> >           transitions { if do_cleanup then select shutdown; }
> >    
> >    }
> >    
> >    final state shutdown {
> >    
> >           entry {
> >           
> >                // Cleanup B group
> >                do B1.stop() ; do B2.stop();
> >                do B1.cleanup() ; do B2.cleanup();
> >                
> >                // Cleanup A group
> >                do A1.stop() ; do A2.stop();
> >                do A1.cleanup() ; do A2.cleanup();
> >           
> >           }
> >    
> >    }
> > 
> > }
> > RootMachine SetupShutdown deploygroups;
> > 

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

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:
> >

> > <properties>
> > <struct name="A1" type="XType" />
> > <struct name="A2" type="YType" />
> > <struct name="B1" type="ZType" />
> > <struct name="B2" type="ZType" />
> > </properties>
> > 

> > StateMachine SetupShutdown {
> > 
> >    var bool do_cleanup = false;
> >    initial state setup {
> >    
> >           entry {
> >           
> >                // Configure A group
> >                do A1.configure() ; do A2.configure();
> >                do connectTwoPorts("A1","Port1", "A2","PortFoo");
> >                do A1.start() ; do A2.start();
> >                
> >                // Configure B group
> >                do B1.configure() ; do B2.configure();
> >                do connectTwoPorts("B1","PortBar", "A2","PortFoo");
> >                do B1.start() ; do B2.start();
> >           
> >           }
> >           transitions { if do_cleanup then select shutdown; }
> >    
> >    }
> >    
> >    final state shutdown {
> >    
> >           entry {
> >           
> >                // Cleanup B group
> >                do B1.stop() ; do B2.stop();
> >                do B1.cleanup() ; do B2.cleanup();
> >                
> >                // Cleanup A group
> >                do A1.stop() ; do A2.stop();
> >                do A1.cleanup() ; do A2.cleanup();
> >           
> >           }
> >    
> >    }
> > 
> > }
> > RootMachine SetupShutdown deploygroups;
> > 

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

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:
> >

> > <properties>
> > <struct name="A1" type="XType" />
> > <struct name="A2" type="YType" />
> > <struct name="B1" type="ZType" />
> > <struct name="B2" type="ZType" />
> > </properties>
> > 

> > StateMachine SetupShutdown {
> > 
> >    var bool do_cleanup = false;
> >    initial state setup {
> >    
> >           entry {
> >           
> >                // Configure A group
> >                do A1.configure() ; do A2.configure();
> >                do connectTwoPorts("A1","Port1", "A2","PortFoo");
> >                do A1.start() ; do A2.start();
> >                
> >                // Configure B group
> >                do B1.configure() ; do B2.configure();
> >                do connectTwoPorts("B1","PortBar", "A2","PortFoo");
> >                do B1.start() ; do B2.start();
> >           
> >           }
> >           transitions { if do_cleanup then select shutdown; }
> >    
> >    }
> >    
> >    final state shutdown {
> >    
> >           entry {
> >           
> >                // Cleanup B group
> >                do B1.stop() ; do B2.stop();
> >                do B1.cleanup() ; do B2.cleanup();
> >                
> >                // Cleanup A group
> >                do A1.stop() ; do A2.stop();
> >                do A1.cleanup() ; do A2.cleanup();
> >           
> >           }
> >    
> >    }
> > 
> > }
> > RootMachine SetupShutdown deploygroups;
> > 

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

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:
> >

> > <properties>
> > <struct name="A1" type="XType" />
> > <struct name="A2" type="YType" />
> > <struct name="B1" type="ZType" />
> > <struct name="B2" type="ZType" />
> > </properties>
> > 

> > StateMachine SetupShutdown {
> > 
> >    var bool do_cleanup = false;
> >    initial state setup {
> >    
> >           entry {
> >           
> >                // Configure A group
> >                do A1.configure() ; do A2.configure();
> >                do connectTwoPorts("A1","Port1", "A2","PortFoo");
> >                do A1.start() ; do A2.start();
> >                
> >                // Configure B group
> >                do B1.configure() ; do B2.configure();
> >                do connectTwoPorts("B1","PortBar", "A2","PortFoo");
> >                do B1.start() ; do B2.start();
> >           
> >           }
> >           transitions { if do_cleanup then select shutdown; }
> >    
> >    }
> >    
> >    final state shutdown {
> >    
> >           entry {
> >           
> >                // Cleanup B group
> >                do B1.stop() ; do B2.stop();
> >                do B1.cleanup() ; do B2.cleanup();
> >                
> >                // Cleanup A group
> >                do A1.stop() ; do A2.stop();
> >                do A1.cleanup() ; do A2.cleanup();
> >           
> >           }
> >    
> >    }
> > 
> > }
> > RootMachine SetupShutdown deploygroups;
> > 

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

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:
> >

> > <properties>
> > <struct name="A1" type="XType" />
> > <struct name="A2" type="YType" />
> > <struct name="B1" type="ZType" />
> > <struct name="B2" type="ZType" />
> > </properties>
> > 

> > StateMachine SetupShutdown {
> > 
> >    var bool do_cleanup = false;
> >    initial state setup {
> >    
> >           entry {
> >           
> >                // Configure A group
> >                do A1.configure() ; do A2.configure();
> >                do connectTwoPorts("A1","Port1", "A2","PortFoo");
> >                do A1.start() ; do A2.start();
> >                
> >                // Configure B group
> >                do B1.configure() ; do B2.configure();
> >                do connectTwoPorts("B1","PortBar", "A2","PortFoo");
> >                do B1.start() ; do B2.start();
> >           
> >           }
> >           transitions { if do_cleanup then select shutdown; }
> >    
> >    }
> >    
> >    final state shutdown {
> >    
> >           entry {
> >           
> >                // Cleanup B group
> >                do B1.stop() ; do B2.stop();
> >                do B1.cleanup() ; do B2.cleanup();
> >                
> >                // Cleanup A group
> >                do A1.stop() ; do A2.stop();
> >                do A1.cleanup() ; do A2.cleanup();
> >           
> >           }
> >    
> >    }
> > 
> > }
> > RootMachine SetupShutdown deploygroups;
> > 

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

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:
> >

> > <properties>
> > <struct name="A1" type="XType" />
> > <struct name="A2" type="YType" />
> > <struct name="B1" type="ZType" />
> > <struct name="B2" type="ZType" />
> > </properties>
> > 

> > StateMachine SetupShutdown {
> > 
> >    var bool do_cleanup = false;
> >    initial state setup {
> >    
> >           entry {
> >           
> >                // Configure A group
> >                do A1.configure() ; do A2.configure();
> >                do connectTwoPorts("A1","Port1", "A2","PortFoo");
> >                do A1.start() ; do A2.start();
> >                
> >                // Configure B group
> >                do B1.configure() ; do B2.configure();
> >                do connectTwoPorts("B1","PortBar", "A2","PortFoo");
> >                do B1.start() ; do B2.start();
> >           
> >           }
> >           transitions { if do_cleanup then select shutdown; }
> >    
> >    }
> >    
> >    final state shutdown {
> >    
> >           entry {
> >           
> >                // Cleanup B group
> >                do B1.stop() ; do B2.stop();
> >                do B1.cleanup() ; do B2.cleanup();
> >                
> >                // Cleanup A group
> >                do A1.stop() ; do A2.stop();
> >                do A1.cleanup() ; do A2.cleanup();
> >           
> >           }
> >    
> >    }
> > 
> > }
> > RootMachine SetupShutdown deploygroups;
> > 

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

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:
> >

> > <properties>
> > <struct name="A1" type="XType" />
> > <struct name="A2" type="YType" />
> > <struct name="B1" type="ZType" />
> > <struct name="B2" type="ZType" />
> > </properties>
> > 

> > StateMachine SetupShutdown {
> > 
> >    var bool do_cleanup = false;
> >    initial state setup {
> >    
> >           entry {
> >           
> >                // Configure A group
> >                do A1.configure() ; do A2.configure();
> >                do connectTwoPorts("A1","Port1", "A2","PortFoo");
> >                do A1.start() ; do A2.start();
> >                
> >                // Configure B group
> >                do B1.configure() ; do B2.configure();
> >                do connectTwoPorts("B1","PortBar", "A2","PortFoo");
> >                do B1.start() ; do B2.start();
> >           
> >           }
> >           transitions { if do_cleanup then select shutdown; }
> >    
> >    }
> >    
> >    final state shutdown {
> >    
> >           entry {
> >           
> >                // Cleanup B group
> >                do B1.stop() ; do B2.stop();
> >                do B1.cleanup() ; do B2.cleanup();
> >                
> >                // Cleanup A group
> >                do A1.stop() ; do A2.stop();
> >                do A1.cleanup() ; do A2.cleanup();
> >           
> >           }
> >    
> >    }
> > 
> > }
> > RootMachine SetupShutdown deploygroups;
> > 

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

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:
> >

> > <properties>
> > <struct name="A1" type="XType" />
> > <struct name="A2" type="YType" />
> > <struct name="B1" type="ZType" />
> > <struct name="B2" type="ZType" />
> > </properties>
> > 

> > StateMachine SetupShutdown {
> > 
> >    var bool do_cleanup = false;
> >    initial state setup {
> >    
> >           entry {
> >           
> >                // Configure A group
> >                do A1.configure() ; do A2.configure();
> >                do connectTwoPorts("A1","Port1", "A2","PortFoo");
> >                do A1.start() ; do A2.start();
> >                
> >                // Configure B group
> >                do B1.configure() ; do B2.configure();
> >                do connectTwoPorts("B1","PortBar", "A2","PortFoo");
> >                do B1.start() ; do B2.start();
> >           
> >           }
> >           transitions { if do_cleanup then select shutdown; }
> >    
> >    }
> >    
> >    final state shutdown {
> >    
> >           entry {
> >           
> >                // Cleanup B group
> >                do B1.stop() ; do B2.stop();
> >                do B1.cleanup() ; do B2.cleanup();
> >                
> >                // Cleanup A group
> >                do A1.stop() ; do A2.stop();
> >                do A1.cleanup() ; do A2.cleanup();
> >           
> >           }
> >    
> >    }
> > 
> > }
> > RootMachine SetupShutdown deploygroups;
> > 

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

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:
> >

> > <properties>
> > <struct name="A1" type="XType" />
> > <struct name="A2" type="YType" />
> > <struct name="B1" type="ZType" />
> > <struct name="B2" type="ZType" />
> > </properties>
> > 

> > StateMachine SetupShutdown {
> > 
> >    var bool do_cleanup = false;
> >    initial state setup {
> >    
> >           entry {
> >           
> >                // Configure A group
> >                do A1.configure() ; do A2.configure();
> >                do connectTwoPorts("A1","Port1", "A2","PortFoo");
> >                do A1.start() ; do A2.start();
> >                
> >                // Configure B group
> >                do B1.configure() ; do B2.configure();
> >                do connectTwoPorts("B1","PortBar", "A2","PortFoo");
> >                do B1.start() ; do B2.start();
> >           
> >           }
> >           transitions { if do_cleanup then select shutdown; }
> >    
> >    }
> >    
> >    final state shutdown {
> >    
> >           entry {
> >           
> >                // Cleanup B group
> >                do B1.stop() ; do B2.stop();
> >                do B1.cleanup() ; do B2.cleanup();
> >                
> >                // Cleanup A group
> >                do A1.stop() ; do A2.stop();
> >                do A1.cleanup() ; do A2.cleanup();
> >           
> >           }
> >    
> >    }
> > 
> > }
> > RootMachine SetupShutdown deploygroups;
> > 

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

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:
> >

> > <properties>
> > <struct name="A1" type="XType" />
> > <struct name="A2" type="YType" />
> > <struct name="B1" type="ZType" />
> > <struct name="B2" type="ZType" />
> > </properties>
> > 

> > StateMachine SetupShutdown {
> > 
> >    var bool do_cleanup = false;
> >    initial state setup {
> >    
> >           entry {
> >           
> >                // Configure A group
> >                do A1.configure() ; do A2.configure();
> >                do connectTwoPorts("A1","Port1", "A2","PortFoo");
> >                do A1.start() ; do A2.start();
> >                
> >                // Configure B group
> >                do B1.configure() ; do B2.configure();
> >                do connectTwoPorts("B1","PortBar", "A2","PortFoo");
> >                do B1.start() ; do B2.start();
> >           
> >           }
> >           transitions { if do_cleanup then select shutdown; }
> >    
> >    }
> >    
> >    final state shutdown {
> >    
> >           entry {
> >           
> >                // Cleanup B group
> >                do B1.stop() ; do B2.stop();
> >                do B1.cleanup() ; do B2.cleanup();
> >                
> >                // Cleanup A group
> >                do A1.stop() ; do A2.stop();
> >                do A1.cleanup() ; do A2.cleanup();
> >           
> >           }
> >    
> >    }
> > 
> > }
> > RootMachine SetupShutdown deploygroups;
> > 

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

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:
> >

> > <properties>
> > <struct name="A1" type="XType" />
> > <struct name="A2" type="YType" />
> > <struct name="B1" type="ZType" />
> > <struct name="B2" type="ZType" />
> > </properties>
> > 

> > StateMachine SetupShutdown {
> > 
> >    var bool do_cleanup = false;
> >    initial state setup {
> >    
> >           entry {
> >           
> >                // Configure A group
> >                do A1.configure() ; do A2.configure();
> >                do connectTwoPorts("A1","Port1", "A2","PortFoo");
> >                do A1.start() ; do A2.start();
> >                
> >                // Configure B group
> >                do B1.configure() ; do B2.configure();
> >                do connectTwoPorts("B1","PortBar", "A2","PortFoo");
> >                do B1.start() ; do B2.start();
> >           
> >           }
> >           transitions { if do_cleanup then select shutdown; }
> >    
> >    }
> >    
> >    final state shutdown {
> >    
> >           entry {
> >           
> >                // Cleanup B group
> >                do B1.stop() ; do B2.stop();
> >                do B1.cleanup() ; do B2.cleanup();
> >                
> >                // Cleanup A group
> >                do A1.stop() ; do A2.stop();
> >                do A1.cleanup() ; do A2.cleanup();
> >           
> >           }
> >    
> >    }
> > 
> > }
> > RootMachine SetupShutdown deploygroups;
> > 

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.