Mojom for serialization

[Florian Loitsch]

Should we use Mojom for serialization?

Mojom messages are serialized into a byte-format when they are sent from one endpoint to another. Would it make sense to use this functionality to serialize (for example write to disk) our data structures?

If yes, how would you do it?

Currently the generated output of the Mojom compiler doesn't provide any exposed "serialize" functions, so we would either need to change the output (which doesn't look too hard), or "intercept" the mojom messages. Deserialization would then consist of reading the bits and send them back to a Mojom service.

Wdyt?

[Zach Anderson]

Hi Florian,

For Dart we generate an `encode` method on every struct type. E.g.:

https://github.com/domokit/mojo/blob/master/mojo/dart/packages/_mojo_for_test_only/lib/mojo/examples/echo.mojom.dart#L66

We use it through the method serializeWithHeader that they inherit from the Struct class in our unit tests here:

https://github.com/domokit/mojo/blob/master/mojo/dart/unittests/embedder_tests/bindings_generation_test.dart#L103

Those are the same bytes that we would send over the wire, and if you e.g. wrote them out to disk and read them back in it would be no different.

It seems to me that that is what you're looking for, but maybe it would help if you could explain a bit more if not.

Cheers,

Zach

--
You received this message because you are subscribed to the Google Groups "mojo-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojo-dev+u...@chromium.org.

[Florian Loitsch]

On Fri, Mar 18, 2016 at 3:49 PM, Zach Anderson <z...@google.com> wrote:

Hi Florian,

For Dart we generate an `encode` method on every struct type. E.g.:

https://github.com/domokit/mojo/blob/master/mojo/dart/packages/_mojo_for_test_only/lib/mojo/examples/echo.mojom.dart#L66

We use it through the method serializeWithHeader that they inherit from the Struct class in our unit tests here:

https://github.com/domokit/mojo/blob/master/mojo/dart/unittests/embedder_tests/bindings_generation_test.dart#L103

Those are the same bytes that we would send over the wire, and if you e.g. wrote them out to disk and read them back in it would be no different.

It seems to me that that is what you're looking for, but maybe it would help if you could explain a bit more if not.

I will have to take a closer look at how I could pass my instances to the encode function, but this looks very similar to what I imagined with an explicit "serialize" function. Thanks.

Cheers,

Zach

On Fri, Mar 18, 2016 at 7:10 AM, 'Florian Loitsch' via mojo-dev <mojo...@chromium.org> wrote:

Should we use Mojom for serialization?

Mojom messages are serialized into a byte-format when they are sent from one endpoint to another. Would it make sense to use this functionality to serialize (for example write to disk) our data structures?

If yes, how would you do it?

Currently the generated output of the Mojom compiler doesn't provide any exposed "serialize" functions, so we would either need to change the output (which doesn't look too hard), or "intercept" the mojom messages. Deserialization would then consist of reading the bits and send them back to a Mojom service.

Wdyt?

--
You received this message because you are subscribed to the Google Groups "mojo-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojo-dev+u...@chromium.org.

--

Give a man a fire and he's warm for the whole day,
but set fire to him and he's warm for the rest of his life. - Terry Pratchett

[Viet-Trung Luu]

Note that Vardhan (CCed) is working on improved explicit serialization/deserialization functions for the C++ bindings. I don't know what bindings for other languages support, but I think that the serialization/storage use-case is something we want to support.

I should point out that there are also currently some deficiencies in the serialization format, particularly (but not only) for the storage use-case: e.g., we're currently unable to preserve unknown (i.e., "future") fields in a sane way (this is a deficiency compared to protobufs, cap'n proto, and of course more self-descriptive formats like JSON or VOM). Hopefully we'll address these issues sometime in the near future.