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 On Sun, Jun 2, 2019 at 11:09 PM Ádám Balázs <[email protected]> wrote: > 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 <[email protected]> ezt írta (időpont: 2019. jún. 1., > Szo, 17:58): > >> 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 >> >> On Fri, May 31, 2019 at 11:31 PM Ádám Balázs <[email protected]> wrote: >> >>> 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 >>> >>> -- >>> 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 [email protected]. >>> 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 >>> <https://groups.google.com/d/msgid/capnproto/6b9633ad-1f97-4e7d-bd9c-03a483aaf859%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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 [email protected]. 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/CAJouXQn%3DO4UVhUfLvRRW1J%3DTPFFvEG9_OTxRQ%2BguXvcpzJP%3DdA%40mail.gmail.com.
