support zero-copy services

[protobits]

As far as I undertand, zero-copy is not implemented for services. It would be really useful to have it. For example, if I want to share a large data structure that does not change, it makes more sense to provide a service that allows to retrieve it and store the reference. Otherwise, I'm forced to publish it periodically, which does not make sense.

[dirk-thomas]

While this would be a great feature there is currently no feature development planned for nodelet_core. Without external contributions this improvement is not likely to be addressed by the maintainers. Therefore I will mark the ticket with the milestone untargeted.

That being said we will definitely consider this as an interesting feature for the future development of ROS.

[protobits]

OK. If I get to understand the innards of nodelet/ROS I might try to
contribute it, but I can't ensure this.
However, may I ask why nodelet will not be developed in the near future? Is
this intra-process model not a priority for ROS? I consider this aspect of
ROS a really important feature (for example, for computer-vision tasks
where serializing images is out of the question).
Or is it simply a feature freeze?

On Mon, Apr 14, 2014 at 2:23 AM, Dirk Thomas notifications@git.luolix.topwrote:

While this would be a great feature there is currently no feature
development planned for nodelet_core. Without external contributions this
improvement is not likely to be addressed by the maintainers. Therefore I
will mark the ticket with the milestone untargeted.

That being said we will definitely consider this as an interesting feature
for the future development of ROS.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/15#issuecomment-40334089
.

[dirk-thomas]

Most of the core ROS packages are in "maintained" status rather then being actively developed with new features planned. This is because we (at OSRF) have only a limited amount of time to work on ROS and we decided that it is better spend on the next iteration of ROS. While we still fix major issues with ROS we can't spend a significant amount of work on new features for existing ROS packages. But any pull requests are welcome and will be reviewed / integrated.

[protobits]

Ok, thank you for your response. I will see if I manage to include this
functionality. However, I don't have a very good understanding on how
nodelet achieves its functionality regarding avoiding serialization. I will
ask a question on answers.ros.org about it.

On Mon, Apr 14, 2014 at 2:18 PM, Dirk Thomas notifications@git.luolix.topwrote:

Most of the core ROS packages are in "maintained" status rather then being
actively developed with new features planned. This is because we (at OSRF)
have only a limited amount of time to work on ROS and we decided that it is
better spend on the next iteration of ROS. While we still fix major issues
with ROS we can't spend a significant amount of work on new features for
existing ROS packages. But any pull requests are welcome and will be
reviewed / integrated.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/15#issuecomment-40392855
.

[tfoote]

Note: this is actually a feature request for ros/ros_comm/roscpp not nodelet_core. When you go digging that's where to look. https://github.com/ros/ros_comm

[protobits]

Should I open an issue there then and close this?

[dirk-thomas]

I think the ticket here is perfectly fine since it only applies to nodelets (even if the enhancement ends up needing changes in roscpp).