On Mon, Feb 20, 2012 at 1:02 PM, Herman Bruyninckx
<Herman.Bruyninckx@mech.kuleuven.be> wrote:
> My "horrible legacy" remark was targeted at the component implementations
> that are now massively invading the internet, not about SMACH.

Ok, good :-)

> As I mentioned in another posting: TSP mixes up the coordination of
> behaviour with the coordination of execution of tasks. These are two
> different things so it makes sense not to mix them in one software tool.

I'm afraid our terminology is getting confused, or at least I am
confused. What is your definition of "behavior"?

For me, a behavior is the combination of several tasks to achive a
goal. Tasks, in my terminology, are a "piece of work to be done". In
contrast, in the OROCOS documentation, I sometimes see the term "task"
being used to describe the component that does something. Is that the
meaning you're using?

>> Right, but I didn't say that, I only said to let them know the
>> identity of the /channel/.
> Even that is probably too much to give to a component.

I wasn't going to, as previously explained.

> Not really: each Port _can_ only do the kind of communication that it is
> designed for; its the _communication_ middleware that has to be configured
> (both in connectivity, as in QoS of the communication transfer).

Ok.

That said, despite the (welcome) correction on terminology,
essentially we agree that its not component itself being configured,
right?

>> The thing is, the TSP describes a very similar separation for
>> different reasons. It doesn't make use of the term "port", because the
>> TSP implementations we have studied don't have a concept of external
>> configurability (beyond those provided by the underlying middleware).
> So, it _has_ configurability, and sweeping it under the carpet is not good.

In fact, it doesn't. I don't get this. Earlier, you were very specific
that its not the port being configured, its the middleware, and now
when I say that, the TSP is _not_ being configured, only the
middleware could be (and, in fact, isn't either in my own
implementation), you say that that's the same all of a sudden?

> Than you have been doing quite biased reading :-)

Would you care to provide a specific reference, then? "coordination"
is very general search term that turns up many other approaches, and
"event-driven coordination" in turn seems to have been very specific.

> Our internet and
> telephony systems are not working like that: the connections mostly
> remains, but the addressee configurations change dynamically.

Well, the history of internet and telephony technology is sufficiently
complicated to make it not as clear cut as that (and "connection" has
many meanings in that context), but I get your point.

cheers,
-- 
Ingo Lütkebohle
Bielefeld University
http://www.techfak.uni-bielefeld.de/~iluetkeb/

PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B