Dear Developers!
To understand what I will suggest in this e-mail, you need to be familiar with the current discussion about RTT 2.0
Check first the following two links:
[Streamlined Execution Flow API] and [Message API].
My question is: do we agree that "Message" is the best word to describe the new interface proposed by Peter?
Message would be the "nephew" of the former Command: it has Asynchronous execution, it is non-blocking from the point of view of the caller, it has a cue to execute the callbacks and it is (consequently)thread-safe. It doesn't have completion condition any more, but this is not the point.
Imagine two devices or 2 processes: what do you think when I told you the word __"Message"__?
If we talk about devices connected by ethernet:
1) a sender is the one that sends a message
2) a receiver is the one that receives the message
3) the message is the packet of information that flowed from sender to receiver.
If I think about 2 computer programs:
1) the sender is the process/component that invokes a function
2) the receiver is the process/component that provides the callback function, accepts the invocation and eventually executes the callback.
3) the message is the invocation itserf and all the arguments embedded in it (the information)
This is what the word "Message" makes me think... what about you?
In RTT 2.0, apparently, the message is the entity 1) and 2), it depends if it is provided or required. In my opinion the message is the entity 3).
Does the term "Message" tell you the difference from Method? (Asynchronous, queued execution, etc...)
My suggestion (finally) is to use the old word __"Command"__ instead. It will easier for both new and old users.
I am looking forward to receive your feedback.
Davide
RTT 2.0. Do we all agree about the word "Message"?
Dear Davide,
I think we agree about the word, but not about its meaning :-)
On Wed, Apr 22, 2009 at 06:12:00PM -0000, faconti [..] ... wrote:
>
> Imagine two devices or 2 processes: what do you think when I told you the word __"Message"__?
> If we talk about devices connected by ethernet:
> 1) a sender is the one that sends a message
> 2) a receiver is the one that receives the message
> 3) the message is the packet of information that flowed from sender to receiver.
This is my interpretation, but it is still underspecified: for me a
message is something lowlevel for transferring some data from an out-
to an in port by a communication (both connection and communication
being configurable at deployment). From this basic primitve we
construct higher-level mechanism such as methods and commands as we
know them or Peters reliable messages (e.g. confirmation required).
Peter and I recently discussed about these two message types and
noticed the analogy to git, which has low-level "plumbing" and
higher-level "porcelain" tools.
> My suggestion (finally) is to use the old word __"Command"__ instead. It will easier for both new and old users.
> I am looking forward to receive your feedback.
I don't think it would be easier if we were to use an existing name
for a different concept.
Best regards
Markus
RTT 2.0. Do we all agree about the word "Message"?
I like the suggestion of Klaas.
What do you think of:
( interface user -> interface provider )
AsyncCall() -> AsyncOperation()
SynchCall() -> SyncOperation()
and for the event...
Signal -> AsyncOperation
Signal -> SyncOperation
are the most self explaining, rigorous and "UML like" solution. This would solve also the fact that the class Method and Command are used in RTT 1.X from both user and provider side (but they are added to the interface only on the provider side).
Of course, I don't want to insist or impose my point of view, it is just a suggestion :)
RTT 2.0. Do we all agree about the word "Message"?
On Thu, Apr 23, 2009 at 11:12 AM, <faconti [..] ...> wrote:
> I like the suggestion of Klaas.
Peter admitted that he stopped reading after this sentence. Me too,
but for different reasons :-]
> What do you think of:
>
> ( interface user -> interface provider )
>
> AsyncCall() -> AsyncOperation()
> SynchCall() -> SyncOperation()
+1
> and for the event...
>
> Signal -> AsyncOperation
> Signal -> SyncOperation
Actually, in UML this is rather st. like
transmitting side - recv. side.
Signal -> Reception
Having a Reception in your interface means that you've defined a
"handler" that will react if the signal is sent.
The difference with the "Calls" here is that
- a call (both synch/async) has a destination, a signal has no destination
- Signal Handlers (implementation on the destinations side) are
_always_ asynchronous.
However, although I think only allowing asynchronous handlers is good
for decoupling,
I understood that the latter would be very unconvenient for Sander, so
I don't know wether orocos 2.0 should limit this.
> are the most self explaining, rigorous and "UML like" solution. This would solve also the fact that the class Method and Command are used in RTT 1.X from both user and provider side (but they are added to the interface only on the provider side).
> Of course, I don't want to insist or impose my point of view, it is just a suggestion :)
We all know Peter's motto "If I can't find it using google, it doesn't
exist". In that respect, it's better to repeat yourself from time to
time :-]]
Klaas
ps. Maybe it would also be interesting to have an opinion of someone
who _really_ knows UML well or takes some time to interpret the specs
instead of just me...
RTT 2.0. Do we all agree about the word "Message"?
>
> Actually, in UML this is rather st. like
> transmitting side - recv. side.
>
> Signal -> Reception
>
> Having a Reception in your interface means that you've defined a
> "handler" that will react if the signal is sent.
>
> The difference with the "Calls" here is that
> - a call (both synch/async) has a destination, a signal has no
destination
> - Signal Handlers (implementation on the destinations side) are
> _always_ asynchronous.
>
> However, although I think only allowing asynchronous handlers is good
> for decoupling,
> I understood that the latter would be very unconvenient for Sander, so
> I don't know wether orocos 2.0 should limit this.
>
There is also another reason why we could need this in RTT 2.0 anyway.
It depends on how the decoupling is done. Now it is rather simple, in
asynchronous completion you get the first or last event that is
occurred. No real problem here, if queuing necessary it is up to the
component (also when the queue is full).
How do you plan to do this in RTT 2.0? Somewhere you have to queue
message/events until they are processed, right? How are you going to
handle full queues?
In our case this means stopping the machine ASAP and as safe as
possible. Since you have a queue problem you can't trust on you messages
any more. With synchronous events it is rather simple: every component
can react _immediately_ to a "queue error event", even components that
are in an endless loop (that caused the problem in the fist place).
Yet an other question: How to define queue depth? Not every component
expects as many events.
> ps. Maybe it would also be interesting to have an opinion of someone
> who _really_ knows UML well or takes some time to interpret the specs
> instead of just me...
Klaas, you are doing just fine, UML is coming out of my ears now... ;-)
Sander.
RTT 2.0. Do we all agree about the word "Message"?
On Sat, 25 Apr 2009, Klaas Gadeyne wrote:
[...]
> The difference with the "Calls" here is that
> - a call (both synch/async) has a destination, a signal has no destination
> - Signal Handlers (implementation on the destinations side) are
> _always_ asynchronous.
>
> However, although I think only allowing asynchronous handlers is good
> for decoupling,
> I understood that the latter would be very unconvenient for Sander, so
> I don't know wether orocos 2.0 should limit this.
I think Sander's remark is extremely valuable! Because there are two kinds
of decoupling:
- the one you (and me) are most often talking about, with the meaning of
decoupling the execution of two activities as much as possible.
- the decoupling of not having to know explicitly who the "receiver" will
be of the signals you send. But if you have a single-activity
application, it is a very appropriate policy to have synchronous handling
of your event! (Decoupling of asynchronous activities is irrelevant in
that use case anyway.)
Herman
RTT 2.0. Do we all agree about the word "Message"?
On Wed, 22 Apr 2009, faconti [..] ... wrote:
> To understand what I will suggest in this e-mail, you need to be familiar with the current discussion about RTT 2.0
>
> Check first the following two links:
> [Streamlined Execution Flow API] and [Message API].
>
> My question is: do we agree that "Message" is the best word to describe the new interface proposed by Peter?
> Message would be the "nephew" of the former Command: it has Asynchronous
> execution, it is non-blocking from the point of view of the caller, it
> has a cue to execute the callbacks and it is (consequently)thread-safe.
> It doesn't have completion condition any more, but this is not the point.
Having a queue implies the choice of a _policy_: FIFO, circular, ...
> Imagine two devices or 2 processes: what do you think when I told you the word __"Message"__?
> If we talk about devices connected by ethernet:
> 1) a sender is the one that sends a message
> 2) a receiver is the one that receives the message
> 3) the message is the packet of information that flowed from sender to receiver.
THis is the meaning I indeed have in mind. (Up to the fact that sender and
receiver do not have to know about each other.)
> If I think about 2 computer programs:
> 1) the sender is the process/component that invokes a function
> 2) the receiver is the process/component that provides the callback function, accepts the invocation and eventually executes the callback.
> 3) the message is the invocation itserf and all the arguments embedded in it (the information)
Ok.
> This is what the word "Message" makes me think... what about you?
> In RTT 2.0, apparently, the message is the entity 1) and 2), it depends if it is provided or required. In my opinion the message is the entity 3).
Ok. But 3) cannot exist without some 1) and 2)... (Or rather, it is
useless without them.)
> Does the term "Message" tell you the difference from Method? (Asynchronous, queued execution, etc...)
It does for me.
> My suggestion (finally) is to use the old word __"Command"__ instead. It
> will easier for both new and old users.
> I am looking forward to receive your feedback.
The _semantics_ are different: with a "Command", I expect the receiver to
really so something, with a "Message" I don't (necessarily).
Herman
RTT 2.0. Do we all agree about the word "Message"?
On Wednesday 22 April 2009 20:12:00 faconti [..] ... wrote:
...
>
> This is what the word "Message" makes me think... what about you?
> In RTT 2.0, apparently, the message is the entity 1) and 2), it depends if
> it is provided or required. In my opinion the message is the entity 3).
> Does the term "Message" tell you the difference from Method? (Asynchronous,
> queued execution, etc...)
>
> My suggestion (finally) is to use the old word __"Command"__ instead. It
> will easier for both new and old users. I am looking forward to receive
> your feedback.
I probably shouldn't comment because I'm overly biased. Oh well.
I agree that the thing going over the network is indeed a 'message' or
'packet'. The reason I proposed to use 'Message' was because a message is
'sent' and there is much similarity with the lower level message primitive.
For example, a message going over a socket (or through a mailbox) is meant to
be processed in another thread or process, ie asynchronously.
However, neither the word 'Command' covers what a asynchronous method
invocation is. And Command was too narrow in my opinion as well.
Some guy once said, why don't you call it 'AsynchronousOperation' vs
'SynchronousOperation', but who can say that ten times in a row and then type
it without using a backspace ?
But you already knew my opinion...
Peter
RTT 2.0. Do we all agree about the word "Message"?
On Wed, Apr 22, 2009 at 10:05 PM, Peter Soetens <peter [dot] soetens [..] ...> wrote:
> On Wednesday 22 April 2009 20:12:00 faconti [..] ... wrote:
> ...
>>
>> This is what the word "Message" makes me think... what about you?
>> In RTT 2.0, apparently, the message is the entity 1) and 2), it depends if
>> it is provided or required. In my opinion the message is the entity 3).
This is also the way it is used in UML, see e.g.
<http://publib.boulder.ibm.com/infocenter/rsmhelp/v7r0m0/index.jsp?topic=/com.ibm.xtools.sequence.doc/topics/cmsg_v.html>
Practically speaking, the message is the arrow on sequence diagrams
between instances, and you have basically 3 types of them:
Synchronous Call messages -> a SyncOperation is called on the
destination (think a superset of the current RTT::Method)
Asynchronous Call messages -> an AsyncOperation is called on the
destination (think a superset of the current RTT::Command)
(asynchronous) Signal messages -> a Signal Reception is called in the
destination (think a superset of the current RTT::Event)
>> Does the term "Message" tell you the difference from Method? (Asynchronous,
>> queued execution, etc...)
>>
>> My suggestion (finally) is to use the old word __"Command"__ instead. It
>> will easier for both new and old users. I am looking forward to receive
>> your feedback.
>
> I probably shouldn't comment because I'm overly biased. Oh well.
Oops, me neither then :-)
> I agree that the thing going over the network is indeed a 'message' or
> 'packet'. The reason I proposed to use 'Message' was because a message is
> 'sent' and there is much similarity with the lower level message primitive.
> For example, a message going over a socket (or through a mailbox) is meant to
> be processed in another thread or process, ie asynchronously.
>
> However, neither the word 'Command' covers what a asynchronous method
> invocation is. And Command was too narrow in my opinion as well.
>
> Some guy once said, why don't you call it 'AsynchronousOperation' vs
> 'SynchronousOperation', but who can say that ten times in a row and then type
> it without using a backspace ?
That's why I think a GUI for creating orocos components is important
and good IDEs type for you :-)
And I'm still in favour of the latter, since they nicely separate the
interface from the implementation (cfr. other thread on this ML), and
hence will allow
- the current situation of executing a method when an operation is called
- couple the operation to a callevent which can be used in FSMs and
hence make Markus happy (I hope :-)
> But you already knew my opinion...
And probably mine also, but maybe if I keep repeating myself enough... :-)
Klaas