On 12/06/2010 11:31 AM, Peter Soetens wrote:
> On Wednesday 01 December 2010 11:12:04 Sylvain Joyeux wrote:
>> On 11/30/2010 09:00 PM, Peter Soetens wrote:
>>> On Tuesday 30 November 2010 18:31:49 Sylvain Joyeux wrote:
>>>> There are some small issues, as orogen's deployments + MQ transport
>>>> requires MR#11 to be merged on RTT. Other than that, the test suite
>>>> passes *and* orogen works fine for a big bunch of modules.
>>>
>>> Regarding MR#11: why did you introduce readNewest() ? What's the
>>> difference with using a 'data' connection + read() instead of 'buffered'
>>> connection + readNewest() ?
>>
>> None, and I am not sure it is a good thing ...
>>
>> The RTT::OldData/RTT::NewData thing, in effect, blurred the difference
>> between 'data' and 'buffer' connections, to the point where I was
>> personally not very sure of what was *still* the point of both.
>>
>> I thought about it yesterday evening, and I am definitely not sure that
>> readNewest is a good thing. The idea about it appeared while we were
>> porting our components. The question was "how to be sure that the
>> component is gonna behave right, regardless of the connection policy
>> which is being used". The point is that if a data triggered component
>> that does
>>
>> if (_port.read(value) == RTT::NewData)
>> {
>> }
>>
>> assuming that the connection will be a data connection, then -- when
>> connected with a buffered connection, will have a high latency on the port.
>
> You know the component shouldn't assume anything about the connection policy
> :-)
>
>>
>> As I said, really not sure. So there are two ways to see it: introduce
>> it and see what happens, or don't. I don't mind either way as the
>> supervision layer is creating the connection types for me ;-)
>
> Sorry for the delay on the MR. I want to merge it today asap. I personally
> don't like components making these 'flush' decisions, since they are making
> system level decisions. For example, they don't produce one output for each
> input. When you're going to hardware, that's probably not an issue, and
> omitting readNewest from the API won't stop users from implementing this tiny
> loop themselves.
In principle, I agree with you that everything should be properly
stream-aligned on timestamps and then produce multiple outputs for each
input and so on ...

Except that in practice, it requires a lot of overhead on the part of
the component developer, and therefore is seldom done.

On Mon, 6 Dec 2010, Peter Soetens wrote:

> On Wednesday 01 December 2010 11:12:04 Sylvain Joyeux wrote:
>> On 11/30/2010 09:00 PM, Peter Soetens wrote:
>>> On Tuesday 30 November 2010 18:31:49 Sylvain Joyeux wrote:
>>>> There are some small issues, as orogen's deployments + MQ transport
>>>> requires MR#11 to be merged on RTT. Other than that, the test suite
>>>> passes *and* orogen works fine for a big bunch of modules.
>>>
>>> Regarding MR#11: why did you introduce readNewest() ? What's the
>>> difference with using a 'data' connection + read() instead of 'buffered'
>>> connection + readNewest() ?
>>
>> None, and I am not sure it is a good thing ...
>>
>> The RTT::OldData/RTT::NewData thing, in effect, blurred the difference
>> between 'data' and 'buffer' connections, to the point where I was
>> personally not very sure of what was *still* the point of both.
>>
>> I thought about it yesterday evening, and I am definitely not sure that
>> readNewest is a good thing. The idea about it appeared while we were
>> porting our components. The question was "how to be sure that the
>> component is gonna behave right, regardless of the connection policy
>> which is being used". The point is that if a data triggered component
>> that does
>>
>> if (_port.read(value) == RTT::NewData)
>> {
>> }
>>
>> assuming that the connection will be a data connection, then -- when
>> connected with a buffered connection, will have a high latency on the port.
>
> You know the component shouldn't assume anything about the connection policy
> :-)
>
>>
>> As I said, really not sure. So there are two ways to see it: introduce
>> it and see what happens, or don't. I don't mind either way as the
>> supervision layer is creating the connection types for me ;-)
>
> Sorry for the delay on the MR. I want to merge it today asap. I personally
> don't like components making these 'flush' decisions, since they are making
> system level decisions. For example, they don't produce one output for each
> input. When you're going to hardware, that's probably not an issue, and
> omitting readNewest from the API won't stop users from implementing this tiny
> loop themselves.
>
> Any one else an opinion on this ?

What is "this" exactly?

> Peter

Herman