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/CADWi_B-oC1gt%3DURmqZR6zof_rWFNUtaLBb%3DuPgMMwATuO7-wBg%40mail.gmail.com.
