While components should certainly not make assumptions about to whom
their ports are connected, it is absolute necessary for on-line
visualization/debugging to be able to determine that information. For
example if we want to connect with a visualization tool to a running
system and generate a deployment view of the system, we need to be
able to figure this out.
Of course this has potential to be misued, thus it should be clearly
marked a "rtt plumbing" command.
How hard would it be to add this?
Best regards
Markus
Feature request: find out how ports are connected
On Saturday 31 October 2009 13:35:45 Markus Klotzbuecher wrote:
> While components should certainly not make assumptions about to whom
> their ports are connected, it is absolute necessary for on-line
> visualization/debugging to be able to determine that information. For
> example if we want to connect with a visualization tool to a running
> system and generate a deployment view of the system, we need to be
> able to figure this out.
I am actually wondering *why* you need such a feature. By definition, "someone"
has to build the connections, so it would be better to use that "someone" as a
source of information as to what is the communication network, no ?
Feature request: find out how ports are connected
On Mon, Nov 02, 2009 at 12:27:40PM +0100, Sylvain Joyeux wrote:
> On Saturday 31 October 2009 13:35:45 Markus Klotzbuecher wrote:
> > While components should certainly not make assumptions about to whom
> > their ports are connected, it is absolute necessary for on-line
> > visualization/debugging to be able to determine that information. For
> > example if we want to connect with a visualization tool to a running
> > system and generate a deployment view of the system, we need to be
> > able to figure this out.
>
> I am actually wondering *why* you need such a feature. By definition, "someone"
> has to build the connections, so it would be better to use that "someone" as a
> source of information as to what is the communication network, no ?
That's fine for me, I don't really care where the information comes
from. OTOH if that "someone" crashes the information will be lost. A
robust system should be able recover.
Markus
Feature request: find out how ports are connected
On Sat, Oct 31, 2009 at 13:35, Markus Klotzbuecher
<markus [dot] klotzbuecher [..] ...> wrote:
> While components should certainly not make assumptions about to whom
> their ports are connected, it is absolute necessary for on-line
> visualization/debugging to be able to determine that information. For
> example if we want to connect with a visualization tool to a running
> system and generate a deployment view of the system, we need to be
> able to figure this out.
>
> Of course this has potential to be misued, thus it should be clearly
> marked a "rtt plumbing" command.
>
> How hard would it be to add this?
I see only two ways of implementing this:
1. Extend the PortInterface to allow traversal of each connection.
The visualisation code must than traverse each connection and be
smart enough to figure out the topology. It needs to re-scan the
network regularily to detect changes.
2. Let each connection register itself when created/destroyed.
The visualisation code must only listen for (de-)registrations,
similar to an OSGi approach.
If anyone doubted, I favour (2). I see this part of a larger framework
which will allow powerful visualisations, but also supervision
frameworks. Imho, at least each TaskContext, provides & requires
interface, dataport, and connection that 'appears' or 'disappears' in
a running system must say so to a 'discovery' service. Any tool can
tap into that service to learn about the layout of the application
(and interact with it!).
This discovery service is just another generic Orocos component that
can work closely with the deployer or other supervision systems. This
would also solve our reconnection problems, since the deployer just
needs a configuration layout, and looks up for each appearing element
what to do with it. You get instant and automatic reconnection for
free if a component crashes and re-appears again.
Peter
Feature request: find out how ports are connected
On Sat, Oct 31, 2009 at 04:11:30PM +0100, Peter Soetens wrote:
> On Sat, Oct 31, 2009 at 13:35, Markus Klotzbuecher
> <markus [dot] klotzbuecher [..] ...> wrote:
> > While components should certainly not make assumptions about to whom
> > their ports are connected, it is absolute necessary for on-line
> > visualization/debugging to be able to determine that information. For
> > example if we want to connect with a visualization tool to a running
> > system and generate a deployment view of the system, we need to be
> > able to figure this out.
> >
> > Of course this has potential to be misued, thus it should be clearly
> > marked a "rtt plumbing" command.
> >
> > How hard would it be to add this?
>
> I see only two ways of implementing this:
> 1. Extend the PortInterface to allow traversal of each connection.
> The visualisation code must than traverse each connection and be
> smart enough to figure out the topology. It needs to re-scan the
> network regularily to detect changes.
> 2. Let each connection register itself when created/destroyed.
> The visualisation code must only listen for (de-)registrations,
> similar to an OSGi approach.
>
> If anyone doubted, I favour (2). I see this part of a larger framework
> which will allow powerful visualisations, but also supervision
> frameworks. Imho, at least each TaskContext, provides & requires
> interface, dataport, and connection that 'appears' or 'disappears' in
> tap into that service to learn about the layout of the application
> (and interact with it!).
In other words the elements you list can serve as event sources
themselves...
> This discovery service is just another generic Orocos component that
> can work closely with the deployer or other supervision systems. This
> would also solve our reconnection problems, since the deployer just
> needs a configuration layout, and looks up for each appearing element
> what to do with it. You get instant and automatic reconnection for
> free if a component crashes and re-appears again.
Ok! While suggestion 1 is probably sufficient for what I had in mind,
2 is of course cleaner and more generic. But even in scenario 2, if I
don't know about the current connection topology there is no way to
find out unless the deployer stores this information and makes it
available, right?
What are your plans wrt OSGi, it's not a 2.0 thing, is it?
Markus
Feature request: find out how ports are connected
On Sat, Oct 31, 2009 at 18:15, Markus Klotzbuecher
<markus [dot] klotzbuecher [..] ...> wrote:
> On Sat, Oct 31, 2009 at 04:11:30PM +0100, Peter Soetens wrote:
>> On Sat, Oct 31, 2009 at 13:35, Markus Klotzbuecher
>> <markus [dot] klotzbuecher [..] ...> wrote:
>> > While components should certainly not make assumptions about to whom
>> > their ports are connected, it is absolute necessary for on-line
>> > visualization/debugging to be able to determine that information. For
>> > example if we want to connect with a visualization tool to a running
>> > system and generate a deployment view of the system, we need to be
>> > able to figure this out.
>> >
>> > Of course this has potential to be misued, thus it should be clearly
>> > marked a "rtt plumbing" command.
>> >
>> > How hard would it be to add this?
>>
>> I see only two ways of implementing this:
>> 1. Extend the PortInterface to allow traversal of each connection.
>> The visualisation code must than traverse each connection and be
>> smart enough to figure out the topology. It needs to re-scan the
>> network regularily to detect changes.
>> 2. Let each connection register itself when created/destroyed.
>> The visualisation code must only listen for (de-)registrations,
>> similar to an OSGi approach.
>>
>> If anyone doubted, I favour (2). I see this part of a larger framework
>> which will allow powerful visualisations, but also supervision
>> frameworks. Imho, at least each TaskContext, provides & requires
>> interface, dataport, and connection that 'appears' or 'disappears' in
>> tap into that service to learn about the layout of the application
>> (and interact with it!).
>
> In other words the elements you list can serve as event sources
> themselves...
Yes, but not in the definition of RTT 1.x/2.0 'Event'. Instead of
emitting such an event, they'll have to lookup a proces-local
interface to which to notify their existence. It's not clear yet if
this interface is to be implemented by a process-local OCL component,
or that there is a stub in place that forwards the call to such a
(remote) component.
>
>> This discovery service is just another generic Orocos component that
>> can work closely with the deployer or other supervision systems. This
>> would also solve our reconnection problems, since the deployer just
>> needs a configuration layout, and looks up for each appearing element
>> what to do with it. You get instant and automatic reconnection for
>> free if a component crashes and re-appears again.
>
> Ok! While suggestion 1 is probably sufficient for what I had in mind,
> 2 is of course cleaner and more generic. But even in scenario 2, if I
> don't know about the current connection topology there is no way to
> find out unless the deployer stores this information and makes it
> available, right?
It depends. If the event is "connection 'A' created from peer1 to
peer2" and the peers are listed by object reference instead of by
name, you can rebuild the whole map.
>
> What are your plans wrt OSGi, it's not a 2.0 thing, is it?
For clarity: there's no way we can be OSGi compatible. It's a *Java*
standard, it is not language-independent. But we can try to adapt its
fundamental model, which is pretty simple by the way. Doing that in
2.x is more realistically, but I want the basics in there such that we
don't need a 3.x release to get it as we want it.
Peter
Feature request: find out how ports are connected
On Mon, Nov 02, 2009 at 09:40:09AM +0100, Peter Soetens wrote:
> On Sat, Oct 31, 2009 at 18:15, Markus Klotzbuecher
> <markus [dot] klotzbuecher [..] ...> wrote:
> > On Sat, Oct 31, 2009 at 04:11:30PM +0100, Peter Soetens wrote:
> >> On Sat, Oct 31, 2009 at 13:35, Markus Klotzbuecher
> >> <markus [dot] klotzbuecher [..] ...> wrote:
> >> > While components should certainly not make assumptions about to whom
> >> > their ports are connected, it is absolute necessary for on-line
> >> > visualization/debugging to be able to determine that information. For
> >> > example if we want to connect with a visualization tool to a running
> >> > system and generate a deployment view of the system, we need to be
> >> > able to figure this out.
> >> >
> >> > Of course this has potential to be misued, thus it should be clearly
> >> > marked a "rtt plumbing" command.
> >> >
> >> > How hard would it be to add this?
> >>
> >> I see only two ways of implementing this:
> >> 1. Extend the PortInterface to allow traversal of each connection.
> >> The visualisation code must than traverse each connection and be
> >> smart enough to figure out the topology. It needs to re-scan the
> >> network regularily to detect changes.
> >> 2. Let each connection register itself when created/destroyed.
> >> The visualisation code must only listen for (de-)registrations,
> >> similar to an OSGi approach.
> >>
> >> If anyone doubted, I favour (2). I see this part of a larger framework
> >> which will allow powerful visualisations, but also supervision
> >> frameworks. Imho, at least each TaskContext, provides & requires
> >> interface, dataport, and connection that 'appears' or 'disappears' in
> >> tap into that service to learn about the layout of the application
> >> (and interact with it!).
> >
> > In other words the elements you list can serve as event sources
> > themselves...
>
> Yes, but not in the definition of RTT 1.x/2.0 'Event'. Instead of
> emitting such an event, they'll have to lookup a proces-local
> interface to which to notify their existence. It's not clear yet if
> this interface is to be implemented by a process-local OCL component,
> or that there is a stub in place that forwards the call to such a
> (remote) component.
But why not use simple 2.0 PortEvents, then each of these entities per
default a standard "OsGI-alike" Event Port which the deployer then can
connect to the process local Coordinator. No extra policy required!
> >> This discovery service is just another generic Orocos component that
> >> can work closely with the deployer or other supervision systems. This
> >> would also solve our reconnection problems, since the deployer just
> >> needs a configuration layout, and looks up for each appearing element
> >> what to do with it. You get instant and automatic reconnection for
> >> free if a component crashes and re-appears again.
> >
> > Ok! While suggestion 1 is probably sufficient for what I had in mind,
> > 2 is of course cleaner and more generic. But even in scenario 2, if I
> > don't know about the current connection topology there is no way to
> > find out unless the deployer stores this information and makes it
> > available, right?
>
> It depends. If the event is "connection 'A' created from peer1 to
> peer2" and the peers are listed by object reference instead of by
> name, you can rebuild the whole map.
Ok, but I'd have to be there from the start.
> > What are your plans wrt OSGi, it's not a 2.0 thing, is it?
>
> For clarity: there's no way we can be OSGi compatible. It's a *Java*
> standard, it is not language-independent. But we can try to adapt its
> fundamental model, which is pretty simple by the way. Doing that in
> 2.x is more realistically, but I want the basics in there such that we
> don't need a 3.x release to get it as we want it.
Yes, choosing a minimal and sensible semantic subset sound good!
Markus
Feature request: find out how ports are connected
On Mon, Nov 02, 2009 at 09:40:09AM +0100, Peter Soetens wrote:
> On Sat, Oct 31, 2009 at 18:15, Markus Klotzbuecher
> <markus [dot] klotzbuecher [..] ...> wrote:
> > On Sat, Oct 31, 2009 at 04:11:30PM +0100, Peter Soetens wrote:
> >> On Sat, Oct 31, 2009 at 13:35, Markus Klotzbuecher
> >> <markus [dot] klotzbuecher [..] ...> wrote:
> >> > While components should certainly not make assumptions about to whom
> >> > their ports are connected, it is absolute necessary for on-line
> >> > visualization/debugging to be able to determine that information. For
> >> > example if we want to connect with a visualization tool to a running
> >> > system and generate a deployment view of the system, we need to be
> >> > able to figure this out.
> >> >
> >> > Of course this has potential to be misued, thus it should be clearly
> >> > marked a "rtt plumbing" command.
> >> >
> >> > How hard would it be to add this?
> >>
> >> I see only two ways of implementing this:
> >> 1. Extend the PortInterface to allow traversal of each connection.
> >> The visualisation code must than traverse each connection and be
> >> smart enough to figure out the topology. It needs to re-scan the
> >> network regularily to detect changes.
> >> 2. Let each connection register itself when created/destroyed.
> >> The visualisation code must only listen for (de-)registrations,
> >> similar to an OSGi approach.
> >>
> >> If anyone doubted, I favour (2). I see this part of a larger framework
> >> which will allow powerful visualisations, but also supervision
> >> frameworks. Imho, at least each TaskContext, provides & requires
> >> interface, dataport, and connection that 'appears' or 'disappears' in
> >> tap into that service to learn about the layout of the application
> >> (and interact with it!).
> >
> > In other words the elements you list can serve as event sources
> > themselves...
>
> Yes, but not in the definition of RTT 1.x/2.0 'Event'. Instead of
> emitting such an event, they'll have to lookup a proces-local
> interface to which to notify their existence. It's not clear yet if
> this interface is to be implemented by a process-local OCL component,
> or that there is a stub in place that forwards the call to such a
> (remote) component.
But why not use simple 2.0 PortEvents, then each of these entities per
default a standard "OsGI-alike" Event Port which the deployer then can
connect to the process local Coordinator. No extra policy required!
> >> This discovery service is just another generic Orocos component that
> >> can work closely with the deployer or other supervision systems. This
> >> would also solve our reconnection problems, since the deployer just
> >> needs a configuration layout, and looks up for each appearing element
> >> what to do with it. You get instant and automatic reconnection for
> >> free if a component crashes and re-appears again.
> >
> > Ok! While suggestion 1 is probably sufficient for what I had in mind,
> > 2 is of course cleaner and more generic. But even in scenario 2, if I
> > don't know about the current connection topology there is no way to
> > find out unless the deployer stores this information and makes it
> > available, right?
>
> It depends. If the event is "connection 'A' created from peer1 to
> peer2" and the peers are listed by object reference instead of by
> name, you can rebuild the whole map.
Ok, but I'd have to be there from the start.
> > What are your plans wrt OSGi, it's not a 2.0 thing, is it?
>
> For clarity: there's no way we can be OSGi compatible. It's a *Java*
> standard, it is not language-independent. But we can try to adapt its
> fundamental model, which is pretty simple by the way. Doing that in
> 2.x is more realistically, but I want the basics in there such that we
> don't need a 3.x release to get it as we want it.
Yes, choosing a minimal and sensible semantic subset sound good!
Markus
Feature request: find out how ports are connected
On Mon, Nov 2, 2009 at 11:39, Markus Klotzbuecher
<markus [dot] klotzbuecher [..] ...> wrote:
> On Mon, Nov 02, 2009 at 09:40:09AM +0100, Peter Soetens wrote:
>> On Sat, Oct 31, 2009 at 18:15, Markus Klotzbuecher
>> <markus [dot] klotzbuecher [..] ...> wrote:
>> > On Sat, Oct 31, 2009 at 04:11:30PM +0100, Peter Soetens wrote:
>> >> On Sat, Oct 31, 2009 at 13:35, Markus Klotzbuecher
>> >> <markus [dot] klotzbuecher [..] ...> wrote:
>> >> > While components should certainly not make assumptions about to whom
>> >> > their ports are connected, it is absolute necessary for on-line
>> >> > visualization/debugging to be able to determine that information. For
>> >> > example if we want to connect with a visualization tool to a running
>> >> > system and generate a deployment view of the system, we need to be
>> >> > able to figure this out.
>> >> >
>> >> > Of course this has potential to be misued, thus it should be clearly
>> >> > marked a "rtt plumbing" command.
>> >> >
>> >> > How hard would it be to add this?
>> >>
>> >> I see only two ways of implementing this:
>> >> 1. Extend the PortInterface to allow traversal of each connection.
>> >> The visualisation code must than traverse each connection and be
>> >> smart enough to figure out the topology. It needs to re-scan the
>> >> network regularily to detect changes.
>> >> 2. Let each connection register itself when created/destroyed.
>> >> The visualisation code must only listen for (de-)registrations,
>> >> similar to an OSGi approach.
>> >>
>> >> If anyone doubted, I favour (2). I see this part of a larger framework
>> >> which will allow powerful visualisations, but also supervision
>> >> frameworks. Imho, at least each TaskContext, provides & requires
>> >> interface, dataport, and connection that 'appears' or 'disappears' in
>> >> tap into that service to learn about the layout of the application
>> >> (and interact with it!).
>> >
>> > In other words the elements you list can serve as event sources
>> > themselves...
>>
>> Yes, but not in the definition of RTT 1.x/2.0 'Event'. Instead of
>> emitting such an event, they'll have to lookup a proces-local
>> interface to which to notify their existence. It's not clear yet if
>> this interface is to be implemented by a process-local OCL component,
>> or that there is a stub in place that forwards the call to such a
>> (remote) component.
>
> But why not use simple 2.0 PortEvents, then each of these entities per
> default a standard "OsGI-alike" Event Port which the deployer then can
> connect to the process local Coordinator. No extra policy required!
Yes, your coordinator will receive events. But at the lowest level,
there will be function calls to some interface. I'm talking stuff here
user's won't see (plumbing). The user will only see a 'deployment
service' announcing what is happening in the local process. To this
guy your Coordinator connects.
>
>> >> This discovery service is just another generic Orocos component that
>> >> can work closely with the deployer or other supervision systems. This
>> >> would also solve our reconnection problems, since the deployer just
>> >> needs a configuration layout, and looks up for each appearing element
>> >> what to do with it. You get instant and automatic reconnection for
>> >> free if a component crashes and re-appears again.
>> >
>> > Ok! While suggestion 1 is probably sufficient for what I had in mind,
>> > 2 is of course cleaner and more generic. But even in scenario 2, if I
>> > don't know about the current connection topology there is no way to
>> > find out unless the deployer stores this information and makes it
>> > available, right?
>>
>> It depends. If the event is "connection 'A' created from peer1 to
>> peer2" and the peers are listed by object reference instead of by
>> name, you can rebuild the whole map.
>
> Ok, but I'd have to be there from the start.
No you don't. In OSGi, if you start listening for a service, you get
an update of all running instances immediately (ie current status),
and then the updates of added/removed services as time moves on. I'd
like to have this in place too. Otherwise, it's a quite useless
feature, since you can't connect to a process before its created.
Peter
Feature request: find out how ports are connected
> On Mon, Nov 2, 2009 at 11:39, Markus Klotzbuecher
> <markus [dot] klotzbuecher [..] ...> wrote:
> > On Mon, Nov 02, 2009 at 09:40:09AM +0100, Peter Soetens wrote:
> >> On Sat, Oct 31, 2009 at 18:15, Markus Klotzbuecher
> >> <markus [dot] klotzbuecher [..] ...> wrote:
> >> > On Sat, Oct 31, 2009 at 04:11:30PM +0100, Peter Soetens wrote:
> >> >> On Sat, Oct 31, 2009 at 13:35, Markus Klotzbuecher
> >> >> <markus [dot] klotzbuecher [..] ...> wrote:
> >> >> > While components should certainly not make
> assumptions about to whom
> >> >> > their ports are connected, it is absolute necessary
> for on-line
> >> >> > visualization/debugging to be able to determine that
> information. For
> >> >> > example if we want to connect with a visualization
> tool to a running
> >> >> > system and generate a deployment view of the system,
> we need to be
> >> >> > able to figure this out.
> >> >> >
> >> >> > Of course this has potential to be misued, thus it
> should be clearly
> >> >> > marked a "rtt plumbing" command.
> >> >> >
> >> >> > How hard would it be to add this?
> >> >>
> >> >> I see only two ways of implementing this:
> >> >> 1. Extend the PortInterface to allow traversal of each
> connection.
> >> >> The visualisation code must than traverse each
> connection and be
> >> >> smart enough to figure out the topology. It needs to re-scan the
> >> >> network regularily to detect changes.
> >> >> 2. Let each connection register itself when created/destroyed.
> >> >> The visualisation code must only listen for
> (de-)registrations,
> >> >> similar to an OSGi approach.
> >> >>
> >> >> If anyone doubted, I favour (2). I see this part of a
> larger framework
> >> >> which will allow powerful visualisations, but also supervision
> >> >> frameworks. Imho, at least each TaskContext, provides & requires
> >> >> interface, dataport, and connection that 'appears' or
> 'disappears' in
> >> >> tap into that service to learn about the layout of the
> application
> >> >> (and interact with it!).
> >> >
> >> > In other words the elements you list can serve as event sources
> >> > themselves...
> >>
> >> Yes, but not in the definition of RTT 1.x/2.0 'Event'. Instead of
> >> emitting such an event, they'll have to lookup a proces-local
> >> interface to which to notify their existence. It's not clear yet if
> >> this interface is to be implemented by a process-local OCL
> component,
> >> or that there is a stub in place that forwards the call to such a
> >> (remote) component.
> >
> > But why not use simple 2.0 PortEvents, then each of these
> entities per
> > default a standard "OsGI-alike" Event Port which the
> deployer then can
> > connect to the process local Coordinator. No extra policy required!
>
> Yes, your coordinator will receive events. But at the lowest level,
> there will be function calls to some interface. I'm talking stuff here
> user's won't see (plumbing). The user will only see a 'deployment
> service' announcing what is happening in the local process. To this
> guy your Coordinator connects.
>
> >
> >> >> This discovery service is just another generic Orocos
> component that
> >> >> can work closely with the deployer or other supervision
> systems. This
> >> >> would also solve our reconnection problems, since the
> deployer just
> >> >> needs a configuration layout, and looks up for each
> appearing element
> >> >> what to do with it. You get instant and automatic
> reconnection for
> >> >> free if a component crashes and re-appears again.
> >> >
> >> > Ok! While suggestion 1 is probably sufficient for what I
> had in mind,
> >> > 2 is of course cleaner and more generic. But even in
> scenario 2, if I
> >> > don't know about the current connection topology there
> is no way to
> >> > find out unless the deployer stores this information and makes it
> >> > available, right?
> >>
> >> It depends. If the event is "connection 'A' created from peer1 to
> >> peer2" and the peers are listed by object reference instead of by
> >> name, you can rebuild the whole map.
> >
> > Ok, but I'd have to be there from the start.
>
> No you don't. In OSGi, if you start listening for a service, you get
> an update of all running instances immediately (ie current status),
> and then the updates of added/removed services as time moves on. I'd
> like to have this in place too. Otherwise, it's a quite useless
> feature, since you can't connect to a process before its created.
I'm a fan of (repeated) validation. Something like 1 would seem great
for double checking even with the OSGi style messages in place. It also
seems like it could be a lighter weight interface (read as "good" ;-)
- alexis.
Feature request: find out how ports are connected
On Mon, Nov 02, 2009 at 12:02:02PM +0100, Peter Soetens wrote:
> On Mon, Nov 2, 2009 at 11:39, Markus Klotzbuecher
> <markus [dot] klotzbuecher [..] ...> wrote:
> > On Mon, Nov 02, 2009 at 09:40:09AM +0100, Peter Soetens wrote:
> >> On Sat, Oct 31, 2009 at 18:15, Markus Klotzbuecher
> >> <markus [dot] klotzbuecher [..] ...> wrote:
> >> > On Sat, Oct 31, 2009 at 04:11:30PM +0100, Peter Soetens wrote:
> >> >> On Sat, Oct 31, 2009 at 13:35, Markus Klotzbuecher
> >> >> <markus [dot] klotzbuecher [..] ...> wrote:
> >> >> > While components should certainly not make assumptions about to whom
> >> >> > their ports are connected, it is absolute necessary for on-line
> >> >> > visualization/debugging to be able to determine that information. For
> >> >> > example if we want to connect with a visualization tool to a running
> >> >> > system and generate a deployment view of the system, we need to be
> >> >> > able to figure this out.
> >> >> >
> >> >> > Of course this has potential to be misued, thus it should be clearly
> >> >> > marked a "rtt plumbing" command.
> >> >> >
> >> >> > How hard would it be to add this?
> >> >>
> >> >> I see only two ways of implementing this:
> >> >> 1. Extend the PortInterface to allow traversal of each connection.
> >> >> The visualisation code must than traverse each connection and be
> >> >> smart enough to figure out the topology. It needs to re-scan the
> >> >> network regularily to detect changes.
> >> >> 2. Let each connection register itself when created/destroyed.
> >> >> The visualisation code must only listen for (de-)registrations,
> >> >> similar to an OSGi approach.
> >> >>
> >> >> If anyone doubted, I favour (2). I see this part of a larger framework
> >> >> which will allow powerful visualisations, but also supervision
> >> >> frameworks. Imho, at least each TaskContext, provides & requires
> >> >> interface, dataport, and connection that 'appears' or 'disappears' in
> >> >> tap into that service to learn about the layout of the application
> >> >> (and interact with it!).
> >> >
> >> > In other words the elements you list can serve as event sources
> >> > themselves...
> >>
> >> Yes, but not in the definition of RTT 1.x/2.0 'Event'. Instead of
> >> emitting such an event, they'll have to lookup a proces-local
> >> interface to which to notify their existence. It's not clear yet if
> >> this interface is to be implemented by a process-local OCL component,
> >> or that there is a stub in place that forwards the call to such a
> >> (remote) component.
> >
> > But why not use simple 2.0 PortEvents, then each of these entities per
> > default a standard "OsGI-alike" Event Port which the deployer then can
> > connect to the process local Coordinator. No extra policy required!
>
> Yes, your coordinator will receive events. But at the lowest level,
> there will be function calls to some interface. I'm talking stuff here
> user's won't see (plumbing). The user will only see a 'deployment
> service' announcing what is happening in the local process. To this
> guy your Coordinator connects.
Ok, would it be an extension to Core RTT or something built on top (an
OCL thing) ? Without knowing much about OSGi it appears that defining
a set of RTT Properties and Methods, which need to be defined for a
OSGi-like enabled TaskContext should be sufficient? You see I favor
composition vs. extension :-)
> >> >> This discovery service is just another generic Orocos component that
> >> >> can work closely with the deployer or other supervision systems. This
> >> >> would also solve our reconnection problems, since the deployer just
> >> >> needs a configuration layout, and looks up for each appearing element
> >> >> what to do with it. You get instant and automatic reconnection for
> >> >> free if a component crashes and re-appears again.
> >> >
> >> > Ok! While suggestion 1 is probably sufficient for what I had in mind,
> >> > 2 is of course cleaner and more generic. But even in scenario 2, if I
> >> > don't know about the current connection topology there is no way to
> >> > find out unless the deployer stores this information and makes it
> >> > available, right?
> >>
> >> It depends. If the event is "connection 'A' created from peer1 to
> >> peer2" and the peers are listed by object reference instead of by
> >> name, you can rebuild the whole map.
> >
> > Ok, but I'd have to be there from the start.
>
> No you don't. In OSGi, if you start listening for a service, you get
> an update of all running instances immediately (ie current status),
> and then the updates of added/removed services as time moves on. I'd
> like to have this in place too. Otherwise, it's a quite useless
> feature, since you can't connect to a process before its created.
Ok, sound nice! (as long as it doesn't get in the way of real-time
constraints)
Markus