The specified queue size/depth in rmw interface...

[dirk-thomas]

... currently only ensures that the history depth of the data reader and writer is at least the specified size.

While this allow the user to use vendor specific configuration to override the QoS parameters it prevents the user from setting a not-to-be-changed queue size.

We might want to consider offering both options to the developer and decide which behavior should be the default.

[jacquelinekay]

To be considered in ros2/design#36 or related pull requests

[wjwwood]

@dirk-thomas is this still an issue? Do you remember why depth is only "ensured" and not enforced?

[dirk-thomas]

I have no knowledge of a change in the behavior regarding this so I expect it to be still the same issue.

[wjwwood]

Can answer my second question? Why is it this way in the first place? Is it because of the global default, driven by the dds configuration files?

[dirk-thomas]

Because that is how it is currently implemented: https://github.com/ros2/rmw_connext/blob/e0c06416625153ecb0e56b115dc2d90da3646841/rmw_connext_shared_cpp/include/rmw_connext_shared_cpp/qos.hpp#L95-L107

[wjwwood]

I understand that this is how it's currently implemented, I was asking why was it implemented that way? I was asking if there was a good reason for it, or if it was that this alternative was picked at random. Or if you were aware of any discussion where we discussed the two alternatives.

I finally managed to find the original conversation about this (it was in a collapsed inline comment thread): ros2/rmw_opensplice#31 (comment)

The summary is basically that there needs to be a way to either specify exactly what you want or use the system default and/or optionally allow for the current behavior which is request a history depth, but use the system default if it's bigger.