underscores/snake case vs camelCase naming conventions about gtfs-realtime-bindings HOT 3 CLOSED

@nzphoenix Good question! So there are several questions here, and I'll try to answer them to the best of my knowledge.

When looking at the gtfs-realtime.proto file, field names use underscores like active_period in Alert or current_stop_sequence in VehiclePosition.

Yes - this is the canonical way to represent field names in Protocol Buffer .proto files, with message names in CamelCase. See https://developers.google.com/protocol-buffers/docs/style#message_and_field_names.

However, to use the nodejs bindings (I haven't checked the others), it requires all attributes to be in camelCase and this applies for both input and output, so you get activePeriod and currentStopSequence.

This differs depending on the programming language and protocol buffer compiler used to generate the bindings. If you look at the above link, using the official Google compiler C++ uses snake_case and Java uses camelCase.

It also means the example code here for nodejs doesn't work and should actually be entity.tripUpdate?

I haven't used the NodeJS bindings myself, but I just added another commit (9354c50) to test this, and it looks like you're right - this test passes for me in IntelliJ:

assert.equal(vehicle.trip.tripId, "t0")

So the notation to access the trip ID variable is camelCase for NodeJS, and we should fix the example - please let me know if you can confirm that the above test (or a similar one also testing camelCase access) works for you.

We use fromObject to convert a JSON GTFS-RT representation into Protobuf, and this was developed using underscores in field names. We can pass the data through a converter to change to camelCase, but wondering if I am missing something here? Shouldn't documentation (linked above) either refer to fields in camelCase or the bindings use underscores for both input/output?

The primary use case for Protocol Buffers is writing to binary and then parsing from binary, in which case you don't have an intermediate text format at all - this is how I'm used to using Protocol Buffers. The only case where I've used the text functions is to transform the binary into something human readable to see the contents - but in this case the naming convention doesn't matter because I'm not using it as something machine readable. Unlike the binary format, I'm not sure if the generated text format is standardized across different protocol buffer compilers and languages. I'd welcome feedback from anyone else that has more information about this.

from gtfs-realtime-bindings.

According to Google's documentation, Proto3 supports a canonical encoding in JSON, which can be used for serializing protobuf data into a JSON as a text-based format that can also be handled by all other languages that support Proto3. However, the GTFS-RT spec uses Proto2 syntax rather than Proto3, which means that (as far as I'm aware... and as far as I can find in the official documentation) you can't reliably depend on transferring this Proto2 data by use of JSON serialization helper methods.

from gtfs-realtime-bindings.

Closing this issue, the question has been answered. Thanks @jameslinjl and @barbeau !

from gtfs-realtime-bindings.