Hi
It seems from the documentation that AutoConnect although available,
it is not a good idea to use it at all. This means that defining Peers
is useless outside the context of AutoConnect?
If this is a not a good practice then we should stop using it? Maybe
deprecated AutoConnect?
Anybody out there have a use case that ONLY works with AutoConnect?
-H
AutoConnect == do you use it? Does it make sense? Is it a bad pr
> It seems from the documentation that AutoConnect although available,
> it is not a good idea to use it at all.
I agree using AutoConnect can be a little bit risky, but for simple
applications I use it all the time.
I know that all the developers agree using AutoConnect is not a good idea, but
from a use perspective it is a very convenient tool for simple applications.
> This means that defining Peers
> is useless outside the context of AutoConnect?
Defining Peers HAS a meaning beside the context of AutoConnect!
> If this is a not a good practice then we should stop using it? Maybe
> deprecated AutoConnect?
Please no. I still think it is useful from a user perspective for simple
applications. Now the documentation clearly states that you should be careful
when using it, which is just fine. It makes users think about which connections
will be made by AutoConnect.
>
> Anybody out there have a use case that ONLY works with AutoConnect?
There is no applications that will only work with AutoConnect, since you can
replace every connection that would automatically be created by AutoConnect by
an explicit connection.
Tinne
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On Wed, 15 Dec 2010, Hugo Garcia wrote:
> It seems from the documentation that AutoConnect although available,
> it is not a good idea to use it at all.
This is a but of an overstatement :-) It is a _deployment policy_ that is
useful in some use cases.
> This means that defining Peers
> is useless outside the context of AutoConnect?
>
> If this is a not a good practice then we should stop using it? Maybe
> deprecated AutoConnect?
>
> Anybody out there have a use case that ONLY works with AutoConnect?
Herman
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On 12/15/2010 11:25 AM, Herman Bruyninckx wrote:
> On Wed, 15 Dec 2010, Hugo Garcia wrote:
>
>> It seems from the documentation that AutoConnect although available,
>> it is not a good idea to use it at all.
>
> This is a but of an overstatement :-) It is a _deployment policy_ that is
> useful in some use cases.
This statement makes me go mmmmm..
Yes, in principle, autoconnection is useful *in practice* for simple
systems (i.e. it is a simple tool "that gets the job done")
In general, I do think it is a very bad idea indeed.
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On Wed, Dec 15, 2010 at 11:27:29AM +0100, Sylvain Joyeux wrote:
> On 12/15/2010 11:25 AM, Herman Bruyninckx wrote:
> > On Wed, 15 Dec 2010, Hugo Garcia wrote:
> >
> >> It seems from the documentation that AutoConnect although available,
> >> it is not a good idea to use it at all.
> >
> > This is a but of an overstatement :-) It is a _deployment policy_ that is
> > useful in some use cases.
>
> This statement makes me go mmmmm..
>
> Yes, in principle, autoconnection is useful *in practice* for simple
> systems (i.e. it is a simple tool "that gets the job done")
>
> In general, I do think it is a very bad idea indeed.
I agree.
If we had a way to figure out how components are connecteed at runtime
we could write a deployer operation which dumps the current
connections to xml. This operation would be accessible only
interactively, so users could manually autoconnect once and then dump
the connections to xml for validation and subsequent deployments, just
like it is commonly done for configuring properties. The current
autoconnect could then be deprecated.
Just an idea.
Markus
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On Wednesday 15 December 2010 11:47:53 Markus Klotzbuecher wrote:
> On Wed, Dec 15, 2010 at 11:27:29AM +0100, Sylvain Joyeux wrote:
> > On 12/15/2010 11:25 AM, Herman Bruyninckx wrote:
> > > On Wed, 15 Dec 2010, Hugo Garcia wrote:
> > >> It seems from the documentation that AutoConnect although available,
> > >> it is not a good idea to use it at all.
> > >
> > > This is a but of an overstatement :-) It is a _deployment policy_ that
> > > is useful in some use cases.
> >
> > This statement makes me go mmmmm..
> >
> > Yes, in principle, autoconnection is useful *in practice* for simple
> > systems (i.e. it is a simple tool "that gets the job done")
> >
> > In general, I do think it is a very bad idea indeed.
>
> I agree.
>
> If we had a way to figure out how components are connecteed at runtime
> we could write a deployer operation which dumps the current
> connections to xml. This operation would be accessible only
> interactively, so users could manually autoconnect once and then dump
> the connections to xml for validation and subsequent deployments, just
> like it is commonly done for configuring properties. The current
> autoconnect could then be deprecated.
>
> Just an idea.
And a very good one!!!!
As a user I would really want to at least want to use the taskbrowser to find
out how my components are connected (this is a basic functionality that is
really lacking from my point of view).
The procedure you explain with connecting everyting interactivily once (and
possibly using AutoConnect ) and then dumping the connections to an xml file,
which allows the user the check the connections and still make some manual
adjustments would be JUST GREAT!!!
Tinne (a simple user who really wants better support for connecting
components)
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On Wed, 15 Dec 2010, Markus Klotzbuecher wrote:
> On Wed, Dec 15, 2010 at 11:27:29AM +0100, Sylvain Joyeux wrote:
>> On 12/15/2010 11:25 AM, Herman Bruyninckx wrote:
>>> On Wed, 15 Dec 2010, Hugo Garcia wrote:
>>>
>>>> It seems from the documentation that AutoConnect although available,
>>>> it is not a good idea to use it at all.
>>>
>>> This is a but of an overstatement :-) It is a _deployment policy_ that is
>>> useful in some use cases.
>>
>> This statement makes me go mmmmm..
>>
>> Yes, in principle, autoconnection is useful *in practice* for simple
>> systems (i.e. it is a simple tool "that gets the job done")
>>
>> In general, I do think it is a very bad idea indeed.
>
> I agree.
>
> If we had a way to figure out how components are connecteed at runtime
> we could write a deployer operation which dumps the current
> connections to xml. This operation would be accessible only
> interactively, so users could manually autoconnect once and then dump
> the connections to xml for validation and subsequent deployments, just
> like it is commonly done for configuring properties. The current
> autoconnect could then be deprecated.
>
> Just an idea.
That is not just an idea: that's _the_ answer: the autoconnect thing is a
"deployment activity", and not a property of the "structural model" of a
component-based system.
> Markus
Herman
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On 12/15/2010 11:47 AM, Markus Klotzbuecher wrote:
> If we had a way to figure out how components are connecteed at runtime
> we could write a deployer operation which dumps the current
> connections to xml. This operation would be accessible only
> interactively, so users could manually autoconnect once and then dump
> the connections to xml for validation and subsequent deployments, just
> like it is commonly done for configuring properties. The current
> autoconnect could then be deprecated.
Or instead of implementing gazillions of features in RTT, you could just
use models for your components and compute everything you want based on
that.
Oh wait, it's even already implemented !
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On Wed, Dec 15, 2010 at 11:51:30AM +0100, Sylvain Joyeux wrote:
> On 12/15/2010 11:47 AM, Markus Klotzbuecher wrote:
> > If we had a way to figure out how components are connecteed at runtime
> > we could write a deployer operation which dumps the current
> > connections to xml. This operation would be accessible only
> > interactively, so users could manually autoconnect once and then dump
> > the connections to xml for validation and subsequent deployments, just
> > like it is commonly done for configuring properties. The current
> > autoconnect could then be deprecated.
> Or instead of implementing gazillions of features in RTT, you could just
> use models for your components and compute everything you want based on
> that.
It's essentially the same thing realized in a static way.
Markus
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On 12/15/2010 12:12 PM, Markus Klotzbuecher wrote:
> On Wed, Dec 15, 2010 at 11:51:30AM +0100, Sylvain Joyeux wrote:
>> On 12/15/2010 11:47 AM, Markus Klotzbuecher wrote:
>>> If we had a way to figure out how components are connecteed at runtime
>>> we could write a deployer operation which dumps the current
>>> connections to xml. This operation would be accessible only
>>> interactively, so users could manually autoconnect once and then dump
>>> the connections to xml for validation and subsequent deployments, just
>>> like it is commonly done for configuring properties. The current
>>> autoconnect could then be deprecated.
>> Or instead of implementing gazillions of features in RTT, you could just
>> use models for your components and compute everything you want based on
>> that.
>
> It's essentially the same thing realized in a static way.
"static" is a very overused word.
You can model dynamic port creation. I actually exactly do that.
What practical use-case do you think model-based cannot cover ?
And, in light of this information, is the "dynamic" functionality worth
the effort that would be needed to get it ? And the fact that in what
you propose, you will not be able to generate said network *without
running the software*. Not very practical to me.
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On Wed, Dec 15, 2010 at 12:41:57PM +0100, Sylvain Joyeux wrote:
> On 12/15/2010 12:12 PM, Markus Klotzbuecher wrote:
> > On Wed, Dec 15, 2010 at 11:51:30AM +0100, Sylvain Joyeux wrote:
> >> On 12/15/2010 11:47 AM, Markus Klotzbuecher wrote:
> >>> If we had a way to figure out how components are connecteed at runtime
> >>> we could write a deployer operation which dumps the current
> >>> connections to xml. This operation would be accessible only
> >>> interactively, so users could manually autoconnect once and then dump
> >>> the connections to xml for validation and subsequent deployments, just
> >>> like it is commonly done for configuring properties. The current
> >>> autoconnect could then be deprecated.
> >> Or instead of implementing gazillions of features in RTT, you could just
> >> use models for your components and compute everything you want based on
> >> that.
> >
> > It's essentially the same thing realized in a static way.
> "static" is a very overused word.
>
> You can model dynamic port creation. I actually exactly do that.
>
> What practical use-case do you think model-based cannot cover ?
You are not understanding. I am talking about model-based deployment
too. The only addition is beeing able to derive the deployment model
from the running system at runtime opposed to defining it prior.
It would be useful if you have a bunch of unmodelled legacy
components, connected by "autoconnect" deployments and you would like
to derive a real model from this.
Markus
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On Wed, Dec 15, 2010 at 12:53, Markus Klotzbuecher
<markus [dot] klotzbuecher [..] ...> wrote:
> On Wed, Dec 15, 2010 at 12:41:57PM +0100, Sylvain Joyeux wrote:
>> On 12/15/2010 12:12 PM, Markus Klotzbuecher wrote:
>> > On Wed, Dec 15, 2010 at 11:51:30AM +0100, Sylvain Joyeux wrote:
>> >> On 12/15/2010 11:47 AM, Markus Klotzbuecher wrote:
>> >>> If we had a way to figure out how components are connecteed at runtime
>> >>> we could write a deployer operation which dumps the current
>> >>> connections to xml. This operation would be accessible only
>> >>> interactively, so users could manually autoconnect once and then dump
>> >>> the connections to xml for validation and subsequent deployments, just
>> >>> like it is commonly done for configuring properties. The current
>> >>> autoconnect could then be deprecated.
>> >> Or instead of implementing gazillions of features in RTT, you could just
>> >> use models for your components and compute everything you want based on
>> >> that.
>> >
>> > It's essentially the same thing realized in a static way.
>> "static" is a very overused word.
>>
>> You can model dynamic port creation. I actually exactly do that.
>>
>> What practical use-case do you think model-based cannot cover ?
>
> You are not understanding. I am talking about model-based deployment
> too. The only addition is beeing able to derive the deployment model
> from the running system at runtime opposed to defining it prior.
>
> It would be useful if you have a bunch of unmodelled legacy
> components, connected by "autoconnect" deployments and you would like
> to derive a real model from this.
So a tool to support this would probably have two modes: offline
(static) and online (dynamic).
Where offline:
You would create the apriori static model of a system of components
where they links between ports and separate links between peers is
constructed.
While in online mode:
The services and ports "discovered" could be monitored and selected
manually and saved to the "complemented" static mode. In addition,
they would have to be some kind of conditional language to define when
the services and ports that are discovered should be used thus the
model becomes both a static and a dynamic representation of the whole
system.
-H
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On 15/12/10 21:03, Hugo Garcia wrote:
> On Wed, Dec 15, 2010 at 12:53, Markus Klotzbuecher
> <markus [dot] klotzbuecher [..] ...> wrote:
>> You are not understanding. I am talking about model-based deployment
>> too. The only addition is beeing able to derive the deployment model
>> from the running system at runtime opposed to defining it prior.
>>
>> It would be useful if you have a bunch of unmodelled legacy
>> components, connected by "autoconnect" deployments and you would like
>> to derive a real model from this.
>
> So a tool to support this would probably have two modes: offline
> (static) and online (dynamic).
>
> Where offline:
>
> You would create the apriori static model of a system of components
> where they links between ports and separate links between peers is
> constructed.
>
> While in online mode:
>
> The services and ports "discovered" could be monitored and selected
> manually and saved to the "complemented" static mode. In addition,
> they would have to be some kind of conditional language to define when
> the services and ports that are discovered should be used thus the
> model becomes both a static and a dynamic representation of the whole
> system.
RTSystemEditor does both of these. Not necessarily well, of course...
Geoff
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On 12/15/2010 01:03 PM, Hugo Garcia wrote:
> On Wed, Dec 15, 2010 at 12:53, Markus Klotzbuecher
> <markus [dot] klotzbuecher [..] ...> wrote:
>> On Wed, Dec 15, 2010 at 12:41:57PM +0100, Sylvain Joyeux wrote:
>>> On 12/15/2010 12:12 PM, Markus Klotzbuecher wrote:
>>>> On Wed, Dec 15, 2010 at 11:51:30AM +0100, Sylvain Joyeux wrote:
>>>>> On 12/15/2010 11:47 AM, Markus Klotzbuecher wrote:
>>>>>> If we had a way to figure out how components are connecteed at runtime
>>>>>> we could write a deployer operation which dumps the current
>>>>>> connections to xml. This operation would be accessible only
>>>>>> interactively, so users could manually autoconnect once and then dump
>>>>>> the connections to xml for validation and subsequent deployments, just
>>>>>> like it is commonly done for configuring properties. The current
>>>>>> autoconnect could then be deprecated.
>>>>> Or instead of implementing gazillions of features in RTT, you could just
>>>>> use models for your components and compute everything you want based on
>>>>> that.
>>>>
>>>> It's essentially the same thing realized in a static way.
>>> "static" is a very overused word.
>>>
>>> You can model dynamic port creation. I actually exactly do that.
>>>
>>> What practical use-case do you think model-based cannot cover ?
>>
>> You are not understanding. I am talking about model-based deployment
>> too. The only addition is beeing able to derive the deployment model
>> from the running system at runtime opposed to defining it prior.
>>
>> It would be useful if you have a bunch of unmodelled legacy
>> components, connected by "autoconnect" deployments and you would like
>> to derive a real model from this.
>
> So a tool to support this would probably have two modes: offline
> (static) and online (dynamic).
>
> Where offline:
>
> You would create the apriori static model of a system of components
> where they links between ports and separate links between peers is
> constructed.
>
> While in online mode:
>
> The services and ports "discovered" could be monitored and selected
> manually and saved to the "complemented" static mode. In addition,
> they would have to be some kind of conditional language to define when
> the services and ports that are discovered should be used thus the
> model becomes both a static and a dynamic representation of the whole
> system.
You do *not* need an online mode. If you can "supplement" the static
model -- and even more so if you create a conditional language to manage
that -- it means you *have all the information you need* before runtime.
The effort needed to create this online mode makes no sense on a
practical point of view (I know that it is only my opinion, but I still
have failed to find a case where it did not work).
The existing API already allows to get interface descriptions from
existing components, and that's all that's needed.
And all of that already exists !!!!! Yes, it is poorly documented, but
it does exist. It runs. It adapts robot behaviour online depending on
external factors and plan-based matters. And it is able to take into
account "dynamic" port creation.
Sylvain
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On Wed, Dec 15, 2010 at 13:34, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> On 12/15/2010 01:03 PM, Hugo Garcia wrote:
>>
>> On Wed, Dec 15, 2010 at 12:53, Markus Klotzbuecher
>> <markus [dot] klotzbuecher [..] ...> wrote:
>>>
>>> On Wed, Dec 15, 2010 at 12:41:57PM +0100, Sylvain Joyeux wrote:
>>>>
>>>> On 12/15/2010 12:12 PM, Markus Klotzbuecher wrote:
>>>>>
>>>>> On Wed, Dec 15, 2010 at 11:51:30AM +0100, Sylvain Joyeux wrote:
>>>>>>
>>>>>> On 12/15/2010 11:47 AM, Markus Klotzbuecher wrote:
>>>>>>>
>>>>>>> If we had a way to figure out how components are connecteed at
>>>>>>> runtime
>>>>>>> we could write a deployer operation which dumps the current
>>>>>>> connections to xml. This operation would be accessible only
>>>>>>> interactively, so users could manually autoconnect once and then dump
>>>>>>> the connections to xml for validation and subsequent deployments,
>>>>>>> just
>>>>>>> like it is commonly done for configuring properties. The current
>>>>>>> autoconnect could then be deprecated.
>>>>>>
>>>>>> Or instead of implementing gazillions of features in RTT, you could
>>>>>> just
>>>>>> use models for your components and compute everything you want based
>>>>>> on
>>>>>> that.
>>>>>
>>>>> It's essentially the same thing realized in a static way.
>>>>
>>>> "static" is a very overused word.
>>>>
>>>> You can model dynamic port creation. I actually exactly do that.
>>>>
>>>> What practical use-case do you think model-based cannot cover ?
>>>
>>> You are not understanding. I am talking about model-based deployment
>>> too. The only addition is beeing able to derive the deployment model
>>> from the running system at runtime opposed to defining it prior.
>>>
>>> It would be useful if you have a bunch of unmodelled legacy
>>> components, connected by "autoconnect" deployments and you would like
>>> to derive a real model from this.
>>
>> So a tool to support this would probably have two modes: offline
>> (static) and online (dynamic).
>>
>> Where offline:
>>
>> You would create the apriori static model of a system of components
>> where they links between ports and separate links between peers is
>> constructed.
>>
>> While in online mode:
>>
>> The services and ports "discovered" could be monitored and selected
>> manually and saved to the "complemented" static mode. In addition,
>> they would have to be some kind of conditional language to define when
>> the services and ports that are discovered should be used thus the
>> model becomes both a static and a dynamic representation of the whole
>> system.
>
> You do *not* need an online mode. If you can "supplement" the static model
> -- and even more so if you create a conditional language to manage that --
> it means you *have all the information you need* before runtime.
>
> The effort needed to create this online mode makes no sense on a practical
> point of view (I know that it is only my opinion, but I still have failed to
> find a case where it did not work).
>
> The existing API already allows to get interface descriptions from existing
> components, and that's all that's needed.
>
> And all of that already exists !!!!! Yes, it is poorly documented, but it
> does exist. It runs. It adapts robot behaviour online depending on external
> factors and plan-based matters. And it is able to take into account
> "dynamic" port creation.
>
> Sylvain
>
I think the use case some people have mentioned to me is:
You have two robots and both are mobile robots. You know all about
Robot A but Robot B was brought in from a far away land and all you
know is that they claim it was written using Orocos (of course) and
that it has services spec is written using the Da Vinci Code. So...
you turn them on and then what??? You have your static model and you
want to complement it with what is discovered from the other robot.
How would you do this sitting in front of your computer with the
wonderful IDE we are making here?
-H
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On 12/15/2010 01:43 PM, Hugo Garcia wrote:
>>> So a tool to support this would probably have two modes: offline
>>> (static) and online (dynamic).
>>>
>>> Where offline:
>>>
>>> You would create the apriori static model of a system of components
>>> where they links between ports and separate links between peers is
>>> constructed.
>>>
>>> While in online mode:
>>>
>>> The services and ports "discovered" could be monitored and selected
>>> manually and saved to the "complemented" static mode. In addition,
>>> they would have to be some kind of conditional language to define when
>>> the services and ports that are discovered should be used thus the
>>> model becomes both a static and a dynamic representation of the whole
>>> system.
>>
>> You do *not* need an online mode. If you can "supplement" the static model
>> -- and even more so if you create a conditional language to manage that --
>> it means you *have all the information you need* before runtime.
>>
>> The effort needed to create this online mode makes no sense on a practical
>> point of view (I know that it is only my opinion, but I still have failed to
>> find a case where it did not work).
>>
>> The existing API already allows to get interface descriptions from existing
>> components, and that's all that's needed.
>>
>> And all of that already exists !!!!! Yes, it is poorly documented, but it
>> does exist. It runs. It adapts robot behaviour online depending on external
>> factors and plan-based matters. And it is able to take into account
>> "dynamic" port creation.
>
> I think the use case some people have mentioned to me is:
>
> You have two robots and both are mobile robots. You know all about
> Robot A but Robot B was brought in from a far away land and all you
> know is that they claim it was written using Orocos (of course) and
> that it has services spec is written using the Da Vinci Code. So...
> you turn them on and then what??? You have your static model and you
> want to complement it with what is discovered from the other robot.
> How would you do this sitting in front of your computer with the
> wonderful IDE we are making here?
If you have no semantic whatsoever on the components that are running on
robot B, then any tool will fail. Including the human brain.
If you -- as a human -- are able to tell how robot A can talk to robot
B, it means that they have compatible interfaces / services and that it
is therefore possible to use the models you have for robot A to describe
robot B.
"static" is again a very tricky word.
You could also *at runtime* use the "static" algorithm and map
automatically the service models to robot B tasks and then use the
"static" deployer to compute your network. And that would *definitely*
be a much safer way of integrating a "robot from hell that you don't
know anything about".
Side note: this scenario is very far-fetched. Remember that robot B
needs to *at least* use the same datatypes than robot A. If he does so,
it really means that he has a lot in common with robot A in the first place.
--
Sylvain Joyeux (Dr. Ing.)
Researcher - Space and Security Robotics
DFKI Robotics Innovation Center
Bremen, Robert-Hooke-Straße 5, 28359 Bremen, Germany
Phone: +49 421 218-64136
Fax: +49 421 218-64150
Email: sylvain [dot] joyeux [..] ...
Weitere Informationen: http://www.dfki.de
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On Wed, Dec 15, 2010 at 01:03:03PM +0100, Hugo Garcia wrote:
> On Wed, Dec 15, 2010 at 12:53, Markus Klotzbuecher
> <markus [dot] klotzbuecher [..] ...> wrote:
> > On Wed, Dec 15, 2010 at 12:41:57PM +0100, Sylvain Joyeux wrote:
> >> On 12/15/2010 12:12 PM, Markus Klotzbuecher wrote:
> >> > On Wed, Dec 15, 2010 at 11:51:30AM +0100, Sylvain Joyeux wrote:
> >> >> On 12/15/2010 11:47 AM, Markus Klotzbuecher wrote:
> >> >>> If we had a way to figure out how components are connecteed at runtime
> >> >>> we could write a deployer operation which dumps the current
> >> >>> connections to xml. This operation would be accessible only
> >> >>> interactively, so users could manually autoconnect once and then dump
> >> >>> the connections to xml for validation and subsequent deployments, just
> >> >>> like it is commonly done for configuring properties. The current
> >> >>> autoconnect could then be deprecated.
> >> >> Or instead of implementing gazillions of features in RTT, you could just
> >> >> use models for your components and compute everything you want based on
> >> >> that.
> >> >
> >> > It's essentially the same thing realized in a static way.
> >> "static" is a very overused word.
> >>
> >> You can model dynamic port creation. I actually exactly do that.
> >>
> >> What practical use-case do you think model-based cannot cover ?
> >
> > You are not understanding. I am talking about model-based deployment
> > too. The only addition is beeing able to derive the deployment model
> > from the running system at runtime opposed to defining it prior.
> >
> > It would be useful if you have a bunch of unmodelled legacy
> > components, connected by "autoconnect" deployments and you would like
> > to derive a real model from this.
>
> So a tool to support this would probably have two modes: offline
> (static) and online (dynamic).
>
> Where offline:
>
> You would create the apriori static model of a system of components
> where they links between ports and separate links between peers is
> constructed.
>
> While in online mode:
>
> The services and ports "discovered" could be monitored and selected
> manually and saved to the "complemented" static mode. In addition,
> they would have to be some kind of conditional language to define when
> the services and ports that are discovered should be used thus the
> model becomes both a static and a dynamic representation of the whole
> system.
I would prefer something simpler, in online mode just "point" the IDE
to a system and visualize it in a comprehensible way. Once that works
interacting with the online system (create a new connection or
component, remove one etc. would be nice.)
Just my 2C.
Markus
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On 15/12/10 21:26, Markus Klotzbuecher wrote:
> On Wed, Dec 15, 2010 at 01:03:03PM +0100, Hugo Garcia wrote:
>> So a tool to support this would probably have two modes: offline
>> (static) and online (dynamic).
>>
>> Where offline:
>>
>> You would create the apriori static model of a system of components
>> where they links between ports and separate links between peers is
>> constructed.
>>
>> While in online mode:
>>
>> The services and ports "discovered" could be monitored and selected
>> manually and saved to the "complemented" static mode. In addition,
>> they would have to be some kind of conditional language to define when
>> the services and ports that are discovered should be used thus the
>> model becomes both a static and a dynamic representation of the whole
>> system.
>
> I would prefer something simpler, in online mode just "point" the IDE
> to a system and visualize it in a comprehensible way. Once that works
> interacting with the online system (create a new connection or
> component, remove one etc. would be nice.)
We use a console tool (rtcryo) to do this. It inspects all known
components and saves any that are determined to be part of the system
into an XML or YAML file, which is a specified data model of the
component network. This file can be used later to restore/launch/stop
the system, or passed through the xml-or-yaml-visualisation tool
(rtstodot) to visualise the system (aggregation gives power and all that).
We have the interaction bit, too. While we prefer model-based for full
system development, we find the interactive method useful for twiddling
things when experimenting.
Geoff
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On 12/15/2010 12:53 PM, Markus Klotzbuecher wrote:
> On Wed, Dec 15, 2010 at 12:41:57PM +0100, Sylvain Joyeux wrote:
>> On 12/15/2010 12:12 PM, Markus Klotzbuecher wrote:
>>> On Wed, Dec 15, 2010 at 11:51:30AM +0100, Sylvain Joyeux wrote:
>>>> On 12/15/2010 11:47 AM, Markus Klotzbuecher wrote:
>>>>> If we had a way to figure out how components are connecteed at runtime
>>>>> we could write a deployer operation which dumps the current
>>>>> connections to xml. This operation would be accessible only
>>>>> interactively, so users could manually autoconnect once and then dump
>>>>> the connections to xml for validation and subsequent deployments, just
>>>>> like it is commonly done for configuring properties. The current
>>>>> autoconnect could then be deprecated.
>>>> Or instead of implementing gazillions of features in RTT, you could just
>>>> use models for your components and compute everything you want based on
>>>> that.
>>>
>>> It's essentially the same thing realized in a static way.
>> "static" is a very overused word.
>>
>> You can model dynamic port creation. I actually exactly do that.
>>
>> What practical use-case do you think model-based cannot cover ?
>
> You are not understanding. I am talking about model-based deployment
> too. The only addition is beeing able to derive the deployment model
> from the running system at runtime opposed to defining it prior.
>
> It would be useful if you have a bunch of unmodelled legacy
> components, connected by "autoconnect" deployments and you would like
> to derive a real model from this.
You don't need to implement "a way to know how components are connected
at runtime" for this. You could just dump the list of ports and
properties into an component interface spec (a.k.a. "oroGen spec") and
come back to base one.
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On Wed, Dec 15, 2010 at 12:59:20PM +0100, Sylvain Joyeux wrote:
> On 12/15/2010 12:53 PM, Markus Klotzbuecher wrote:
> > On Wed, Dec 15, 2010 at 12:41:57PM +0100, Sylvain Joyeux wrote:
> >> On 12/15/2010 12:12 PM, Markus Klotzbuecher wrote:
> >>> On Wed, Dec 15, 2010 at 11:51:30AM +0100, Sylvain Joyeux wrote:
> >>>> On 12/15/2010 11:47 AM, Markus Klotzbuecher wrote:
> >>>>> If we had a way to figure out how components are connecteed at runtime
> >>>>> we could write a deployer operation which dumps the current
> >>>>> connections to xml. This operation would be accessible only
> >>>>> interactively, so users could manually autoconnect once and then dump
> >>>>> the connections to xml for validation and subsequent deployments, just
> >>>>> like it is commonly done for configuring properties. The current
> >>>>> autoconnect could then be deprecated.
> >>>> Or instead of implementing gazillions of features in RTT, you could just
> >>>> use models for your components and compute everything you want based on
> >>>> that.
> >>>
> >>> It's essentially the same thing realized in a static way.
> >> "static" is a very overused word.
> >>
> >> You can model dynamic port creation. I actually exactly do that.
> >>
> >> What practical use-case do you think model-based cannot cover ?
> >
> > You are not understanding. I am talking about model-based deployment
> > too. The only addition is beeing able to derive the deployment model
> > from the running system at runtime opposed to defining it prior.
> >
> > It would be useful if you have a bunch of unmodelled legacy
> > components, connected by "autoconnect" deployments and you would like
> > to derive a real model from this.
> You don't need to implement "a way to know how components are connected
> at runtime" for this. You could just dump the list of ports and
> properties into an component interface spec (a.k.a. "oroGen spec") and
Thats step 1, but then you don't know how stuff was connected?
> come back to base one.
I don't understand what "come back to base one" means.
Markus
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On 12/15/2010 01:14 PM, Markus Klotzbuecher wrote:
> On Wed, Dec 15, 2010 at 12:59:20PM +0100, Sylvain Joyeux wrote:
>> On 12/15/2010 12:53 PM, Markus Klotzbuecher wrote:
>>> On Wed, Dec 15, 2010 at 12:41:57PM +0100, Sylvain Joyeux wrote:
>>>> On 12/15/2010 12:12 PM, Markus Klotzbuecher wrote:
>>>>> On Wed, Dec 15, 2010 at 11:51:30AM +0100, Sylvain Joyeux wrote:
>>>>>> On 12/15/2010 11:47 AM, Markus Klotzbuecher wrote:
>>>>>>> If we had a way to figure out how components are connecteed at runtime
>>>>>>> we could write a deployer operation which dumps the current
>>>>>>> connections to xml. This operation would be accessible only
>>>>>>> interactively, so users could manually autoconnect once and then dump
>>>>>>> the connections to xml for validation and subsequent deployments, just
>>>>>>> like it is commonly done for configuring properties. The current
>>>>>>> autoconnect could then be deprecated.
>>>>>> Or instead of implementing gazillions of features in RTT, you could just
>>>>>> use models for your components and compute everything you want based on
>>>>>> that.
>>>>>
>>>>> It's essentially the same thing realized in a static way.
>>>> "static" is a very overused word.
>>>>
>>>> You can model dynamic port creation. I actually exactly do that.
>>>>
>>>> What practical use-case do you think model-based cannot cover ?
>>>
>>> You are not understanding. I am talking about model-based deployment
>>> too. The only addition is beeing able to derive the deployment model
>>> from the running system at runtime opposed to defining it prior.
>>>
>>> It would be useful if you have a bunch of unmodelled legacy
>>> components, connected by "autoconnect" deployments and you would like
>>> to derive a real model from this.
>> You don't need to implement "a way to know how components are connected
>> at runtime" for this. You could just dump the list of ports and
>> properties into an component interface spec (a.k.a. "oroGen spec") and
>
> Thats step 1, but then you don't know how stuff was connected?
Why do you need to ?
As you said yourself, the goal is to show it to the user and have it
double-check on this. Reimplementing AutoConnect is pretty trivial, so
you can do it on top of your models.
>> come back to base one.
>
> I don't understand what "come back to base one" means.
Since you have the interface models, all the static algorithms work like
a charm.
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On Wed, Dec 15, 2010 at 01:16:53PM +0100, Sylvain Joyeux wrote:
> On 12/15/2010 01:14 PM, Markus Klotzbuecher wrote:
> > On Wed, Dec 15, 2010 at 12:59:20PM +0100, Sylvain Joyeux wrote:
> >> On 12/15/2010 12:53 PM, Markus Klotzbuecher wrote:
> >>> On Wed, Dec 15, 2010 at 12:41:57PM +0100, Sylvain Joyeux wrote:
> >>>> On 12/15/2010 12:12 PM, Markus Klotzbuecher wrote:
> >>>>> On Wed, Dec 15, 2010 at 11:51:30AM +0100, Sylvain Joyeux wrote:
> >>>>>> On 12/15/2010 11:47 AM, Markus Klotzbuecher wrote:
> >>>>>>> If we had a way to figure out how components are connecteed at runtime
> >>>>>>> we could write a deployer operation which dumps the current
> >>>>>>> connections to xml. This operation would be accessible only
> >>>>>>> interactively, so users could manually autoconnect once and then dump
> >>>>>>> the connections to xml for validation and subsequent deployments, just
> >>>>>>> like it is commonly done for configuring properties. The current
> >>>>>>> autoconnect could then be deprecated.
> >>>>>> Or instead of implementing gazillions of features in RTT, you could just
> >>>>>> use models for your components and compute everything you want based on
> >>>>>> that.
> >>>>>
> >>>>> It's essentially the same thing realized in a static way.
> >>>> "static" is a very overused word.
> >>>>
> >>>> You can model dynamic port creation. I actually exactly do that.
> >>>>
> >>>> What practical use-case do you think model-based cannot cover ?
> >>>
> >>> You are not understanding. I am talking about model-based deployment
> >>> too. The only addition is beeing able to derive the deployment model
> >>> from the running system at runtime opposed to defining it prior.
> >>>
> >>> It would be useful if you have a bunch of unmodelled legacy
> >>> components, connected by "autoconnect" deployments and you would like
> >>> to derive a real model from this.
> >> You don't need to implement "a way to know how components are connected
> >> at runtime" for this. You could just dump the list of ports and
> >> properties into an component interface spec (a.k.a. "oroGen spec") and
> >
> > Thats step 1, but then you don't know how stuff was connected?
> Why do you need to ?
>
> As you said yourself, the goal is to show it to the user and have it
> double-check on this. Reimplementing AutoConnect is pretty trivial, so
> you can do it on top of your models.
Yes, I agree that would be a sensible option.
Still I think that it would be a very useful and generic feature to
introspect the topology of the system online. You shouldn't
categorically reject all improvements just because they don't fit for
your workflow.
Markus
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On Wed, 15 Dec 2010, Markus Klotzbuecher wrote:
> On Wed, Dec 15, 2010 at 01:16:53PM +0100, Sylvain Joyeux wrote:
>> On 12/15/2010 01:14 PM, Markus Klotzbuecher wrote:
>>> On Wed, Dec 15, 2010 at 12:59:20PM +0100, Sylvain Joyeux wrote:
>>>> On 12/15/2010 12:53 PM, Markus Klotzbuecher wrote:
>>>>> On Wed, Dec 15, 2010 at 12:41:57PM +0100, Sylvain Joyeux wrote:
>>>>>> On 12/15/2010 12:12 PM, Markus Klotzbuecher wrote:
>>>>>>> On Wed, Dec 15, 2010 at 11:51:30AM +0100, Sylvain Joyeux wrote:
>>>>>>>> On 12/15/2010 11:47 AM, Markus Klotzbuecher wrote:
>>>>>>>>> If we had a way to figure out how components are connecteed at runtime
>>>>>>>>> we could write a deployer operation which dumps the current
>>>>>>>>> connections to xml. This operation would be accessible only
>>>>>>>>> interactively, so users could manually autoconnect once and then dump
>>>>>>>>> the connections to xml for validation and subsequent deployments, just
>>>>>>>>> like it is commonly done for configuring properties. The current
>>>>>>>>> autoconnect could then be deprecated.
>>>>>>>> Or instead of implementing gazillions of features in RTT, you could just
>>>>>>>> use models for your components and compute everything you want based on
>>>>>>>> that.
>>>>>>>
>>>>>>> It's essentially the same thing realized in a static way.
>>>>>> "static" is a very overused word.
>>>>>>
>>>>>> You can model dynamic port creation. I actually exactly do that.
>>>>>>
>>>>>> What practical use-case do you think model-based cannot cover ?
>>>>>
>>>>> You are not understanding. I am talking about model-based deployment
>>>>> too. The only addition is beeing able to derive the deployment model
>>>>> from the running system at runtime opposed to defining it prior.
>>>>>
>>>>> It would be useful if you have a bunch of unmodelled legacy
>>>>> components, connected by "autoconnect" deployments and you would like
>>>>> to derive a real model from this.
>>>> You don't need to implement "a way to know how components are connected
>>>> at runtime" for this. You could just dump the list of ports and
>>>> properties into an component interface spec (a.k.a. "oroGen spec") and
>>>
>>> Thats step 1, but then you don't know how stuff was connected?
>> Why do you need to ?
>>
>> As you said yourself, the goal is to show it to the user and have it
>> double-check on this. Reimplementing AutoConnect is pretty trivial, so
>> you can do it on top of your models.
>
> Yes, I agree that would be a sensible option.
>
> Still I think that it would be a very useful and generic feature to
> introspect the topology of the system online.
Introspection is a "must" for future software systems, and hence each
component should, in principle, support it. We are not there yet, of
course. It is also not so clear to me (yet) which component(s) should have
the topology information ready for introspection...
This material is "under inspection" inside the BRICS project, and in the
context of a new project proposal, so personally I will invest quite some
thinking about these issues in the coming years.
> You shouldn't categorically reject all improvements just because they
> don't fit for your workflow.
Outright "rejection" is the best way to make others think hard about why
they definitely need a certain feature :-) (And to make their motivations
explicit on the mailinglist, of course!)
> Markus
Herman
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On 12/15/2010 01:47 PM, Markus Klotzbuecher wrote:
> Yes, I agree that would be a sensible option.
>
> Still I think that it would be a very useful and generic feature to
> introspect the topology of the system online. You shouldn't
> categorically reject all improvements just because they don't fit for
> your workflow.
First of all, I'm in no position to reject anything as I will obviously
not be the one that implements it. If you guys want to spend effort on
that, all the best.
I'm pointing out that the use-case "connection management" is IN MY
OPINION a bad one. And that you would be implementing something that
already exists. Given that implementing a good topology introspection
interface will be a lot of work, I believe that having a good use-case
for it before spending the required effort would make sense.
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On Wed, Dec 15, 2010 at 13:54, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> On 12/15/2010 01:47 PM, Markus Klotzbuecher wrote:
>> Yes, I agree that would be a sensible option.
>>
>> Still I think that it would be a very useful and generic feature to
>> introspect the topology of the system online. You shouldn't
>> categorically reject all improvements just because they don't fit for
>> your workflow.
> First of all, I'm in no position to reject anything as I will obviously
> not be the one that implements it. If you guys want to spend effort on
> that, all the best.
>
> I'm pointing out that the use-case "connection management" is IN MY
> OPINION a bad one. And that you would be implementing something that
> already exists. Given that implementing a good topology introspection
> interface will be a lot of work, I believe that having a good use-case
> for it before spending the required effort would make sense.
> --
How about monitoring and debugging the system dynamically?
-H
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On Wed, Dec 15, 2010 at 01:54:39PM +0100, Sylvain Joyeux wrote:
> On 12/15/2010 01:47 PM, Markus Klotzbuecher wrote:
> > Yes, I agree that would be a sensible option.
> >
> > Still I think that it would be a very useful and generic feature to
> > introspect the topology of the system online. You shouldn't
> > categorically reject all improvements just because they don't fit for
> > your workflow.
> First of all, I'm in no position to reject anything as I will obviously
> not be the one that implements it. If you guys want to spend effort on
> that, all the best.
>
> I'm pointing out that the use-case "connection management" is IN MY
> OPINION a bad one. And that you would be implementing something that
I really do appreciate your opinion.
> already exists. Given that implementing a good topology introspection
> interface will be a lot of work, I believe that having a good use-case
Why do think that implementing this would be a lot of work? After all
the model behind such a topology is only a simple, flat graph?
> for it before spending the required effort would make sense.
I certainly agree with that.
Markus
AutoConnect == do you use it? Does it make sense? Is it a bad pr
On 12/15/2010 02:02 PM, Markus Klotzbuecher wrote:
> On Wed, Dec 15, 2010 at 01:54:39PM +0100, Sylvain Joyeux wrote:
>> On 12/15/2010 01:47 PM, Markus Klotzbuecher wrote:
>>> Yes, I agree that would be a sensible option.
>>>
>>> Still I think that it would be a very useful and generic feature to
>>> introspect the topology of the system online. You shouldn't
>>> categorically reject all improvements just because they don't fit for
>>> your workflow.
>> First of all, I'm in no position to reject anything as I will obviously
>> not be the one that implements it. If you guys want to spend effort on
>> that, all the best.
>>
>> I'm pointing out that the use-case "connection management" is IN MY
>> OPINION a bad one. And that you would be implementing something that
>
> I really do appreciate your opinion.
>
>> already exists. Given that implementing a good topology introspection
>> interface will be a lot of work, I believe that having a good use-case
>
> Why do think that implementing this would be a lot of work? After all
> the model behind such a topology is only a simple, flat graph?
Yeah. Except that if you want to inspect it from the point of view of
the components, it is a *distributed* flat graph. Hence, you will need
*every component* to give you a way to get the data *related to himself*
in a way that allows you to get who is who (how do you refer to other
tasks ? CORBA IDs ? that would be CORBA-specific ...) and then merge all
this information in the "simple, flat graph". Ouch.
And I am not even talking about getting the policy out of the
connections ...