Reading/modifying/writing config structs

[Ádám Balázs]

Hi all,

I'm new in Cap'NProto, I consider using it instead of ProtoBuf2 in a new project.

I have a C++ embedded app and I would like to create a web interface to configure it.

My plan is to describe the configuration structs in Cap'nProto then use the generated code on C++ and Javascript side.

A config scenario would be the following:

1. web app asks for the actual config (Javascript)

2. native app serves the actual config - serialization/write (C++)

3. web app displays the actual config after deserialization/read (Javascript)
4. user can modify the config in the web app - HOW? (Javascript)
5. web app sends back the new config - serialization/write (Javascript)
6. native app uses the new config after deserialization/read (C++)
7. native app can modify the config - HOW? (C++)

4 and 7 are the tricky parts, because as far as I understand the API I can only deserialize a reader that is read only, however I would like to modify and re-serialize it later. In ProtoBuf2 it would be straightforward, but I do not see any barrier in Cap'NProto protocol that prevents this kind of operations. (non-presented fields are zeroed, so there is place to store the modified data).

My questions are the followings:

• Is the described scenario the best approach to do what I want or I should do something totally different?
• Can I deserialize/read into a builder? Or somehow transform a reader into a builder (without copying)
• Should I use the generated C++ / Javascript structs as a direct source of configuration (actual code <-> Cap'nProto structs) or I should introduce "native" structs to interact with (actual code <-> "native" structs <->(serialize/deserialize) Cap'nProto structs)

Thanks: Adam

[Kenton Varda]

Hi Ádám,

You can initialize a Builder from a Reader, like:

    fooBulider.setBar(someBarReader);

Or for the top-level MessageReader/MessageBuilder:

    messageBuilder.setRoot<RootType>(messageReader.getRoot<RootType>());

This does require a copy, but for your use case, that copy is probably not a big deal. Configs usually aren't multi-gigabyte files nor performance-sensitive. :)

In theory, it is also possible to create a MessageBuilder that is directly initialized from existing message data which it then modifies in-place. However, there are some major caveats with this. See:

https://github.com/capnproto/capnproto/blob/3aa2b2aa02edb1c160b154ad74c08c929a02512a/c++/src/capnp/message.h#L168-L187

Regarding your other two questions, it's really up to you. There are legitimate arguments both ways and it'll really come down to the specific use case and your personal taste.

-Kenton

--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+...@googlegroups.com.
Visit this group at https://groups.google.com/group/capnproto.
To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/6b9633ad-1f97-4e7d-bd9c-03a483aaf859%40googlegroups.com.

[Ádám Balázs]

Hi Kenton,

Thank you for your reply! I think it is clear now how to use readers/writers in my case.

I have only one decision remaining: configs are structured and hierarchical. The parent/children relationship will be handled by composition, however I do not know how to handle siblings. For example I will have ImageControl and VideoQuality configs.

I think my options are the following:

1. Have a separated command for each config (set/getImageControl, set/getVideoQuality)
   
2. Have one set/get command and the message would describe the exact scenario
• With unions - all possible commands are enumerated in one huge union
• With raw serialized data - for e.g.: CommandDescriptor{ enum command; data serializedConfig }, then I can switch the command and read the specific config from serializedConfig.

For me the second option with unions seems to be the best, however I do not know if it has any major Cap'NProto-related drawbacks.

Thank you: Adam

[Kenton Varda]

I'd personally go with the union. The only drawback of unions is if for some reason you can't list all possibilities in a single file (e.g. because you want to allow extension by third parties, or something).

-Kenton