Using eCAL with capnproto

[mpghf]

Is anybody using capnproto and eCAL (with C++)? The example seems to suggest reusing the same capnproto builder for each iteration of the the capnproto structure I'm sending - I'm updating fields in a loop before sending the message.

This seems to work the first time, but reusing the builder for complex capnproto structures (like strings) causes the packet to bloat with more zeros each time it's used, and eventually become to big to send.

The capnproto people recommend using a completely new builder each time. When capnproto is used with eCAL, the recommended way to get a builder is using eCAL::capnproto::CPublisher<Packet>::GetBuilder(), and that seems to return a shallow copy to essentially the same builder each time, so that doesn't help.

Creating a new publisher on each iteration doesn't seem to be feasible either.

Any suggestions?

[KerstinKeller]

Hi @mpghf,

We have implemented the CapnProto Publisher / Subscribers, but we're not using them productively. That saying, we're finalizing the API for eCAL 6 (which we hope to release end of January) so now would be a great time to get your input on this.

On the master branch, we have already made some changes, but mainly on the subscribing side.
So what would be a good API? We could also change the API in such a way, that the Send() function takes a Builder, so the user is free to build their objects, and then pass it on?

Basically, the Message API is just a thin layer, that can provide a way to a) serialize / deserialize data and b) provide metadata, that (potentially) allows users to make use of reflection.

[mpghf]

Thanks @KerstinKeller ,

I think having Send() take the Builder as a parameter would be good. That would also match the flatbuffers and protocol buffers APIs. Send() could then take a time parameter too, like the flatbuffers and protocol buffers APIs.

On the other hand, perhaps there's a good reason that capnproto has such a different API?

[KerstinKeller]

No, not really. The "Binary Publisher" API has evolved quite a bit, and previously the message APIs were added on top a bit differently. I think it was mostly out of missing knowledge that the API had been designed the way it has been designed.

And yes, it does make a lot of sense that Send() offers the same kind of functionality, that the other Publishers do. Let's see what we can do about it, I will mention you in a PR.

[mpghf]

Thanks.