On Wednesday, 1 July 2020 at 19:35:26 UTC, JN wrote:
> On Wednesday, 1 July 2020 at 10:27:21 UTC, kdmult wrote:
>>
>> Maybe https://kaitai.io/ will be useful to you.
>
> Looks very similar to Google's Protocol Buffers. What is the main benefit of kaitai over protobuf?

Perhaps their "Format Gallery" [1] or IDE [2].

[1] https://formats.kaitai.io/
[2] https://ide.kaitai.io/

On Wednesday, 1 July 2020 at 19:35:26 UTC, JN wrote:
> On Wednesday, 1 July 2020 at 10:27:21 UTC, kdmult wrote:
>>
>> Maybe https://kaitai.io/ will be useful to you.
>
> Looks very similar to Google's Protocol Buffers. What is the main benefit of kaitai over protobuf?

If you've worked with Protobuf you will know it's hard to specify
certain things, e.g. relationships between values and types. I assume
Kaitai is better at this.

For example, in Protobuf you can't really specify that the value of a
field will determine the type of the next field. It expects you to just
use something like a field for the type id, and a dynamic/byte array
field for the payload, to then do the type casting in application code.

For things like container file formats this makes Protobuf insufficient,
but for its main purpose, defining binary wire protocols, it's not as
much of an issue.

On Monday, 29 June 2020 at 19:39:19 UTC, H. S. Teoh wrote:
> For anything more complex, D's std.process r0x0rs the boat. I highly recommend it.
>
>
> T

This is what I needed to remember for the phobos is awesome post. std.process and even std.path are absolute perfections.

In college we had some assignments in Python where process pipe manipulation was required. This was before std.process and Python set the bar high for this. And when it was added, it met those expectations.

Today, Python feels like such an old language. I can see through all the cruft why people have said it is an easy language. I also get why Go has been seen as a python replacement.

On Thursday, 2 July 2020 at 12:59:59 UTC, Les De Ridder wrote:
>
> For example, in Protobuf you can't really specify that the value of a
> field will determine the type of the next field. It expects you to just
> use something like a field for the type id, and a dynamic/byte array
> field for the payload, to then do the type casting in application code.
>
> For things like container file formats this makes Protobuf insufficient,
> but for its main purpose, defining binary wire protocols, it's not as
> much of an issue.

I'm trying to figure out how to ask this clarifying question. I have not done much with protobuf usage but do agree it isn't really meant for file storage.

I did a parser for open street maps[1] years ago. They utilized protobuf to define the file format of the inner protobuf.

When you say you need a byte array I don't understand why you would not just fill a field with the type you want. But like I said it was years ago and I do not remember if osm would clarify that for me.




1. https://github.com/JesseKPhillips/libosm/blob/master/examples/dump/source/app.d