machinekit / machinetalk-protobuf

Protobuf declarations for machinekit messages
MIT License
10 stars 11 forks source link

Protobuf Extensions and Oneof #42

Open machinekoder opened 8 years ago

machinekoder commented 8 years ago

The protobuf definitions might be easier to understand by using the Protobuf Extensions and Oneof features: https://developers.google.com/protocol-buffers/docs/proto?hl=en

E.g. message types for a certain service could be defined in separate file instead of the types.proto. It would simplify documentation of things that belong together.

mhaberler commented 8 years ago

certainly - also the dictionary feature might be useful

before adopting protobuf 3, I'd like to see a stable release with solid Python bindings (currently considered alpha: https://github.com/google/protobuf/releases)

machinekoder commented 8 years ago

Both features are available in protobuf 2.6. Especially Extensions could be very helpful.

machinekoder commented 8 years ago

Example: The types and messages for a new protcol could be moved into a myprotocol.proto file:

package pb;

import "machinetalk/protobuf/message.proto";

enum MyCoolProtocolType {
   COOL_PING = 1,
   COOL_PONG = 2
}

message MyMessage {
    required MyCoolProtocolType type = 1;
    optional int32 easy = 2;
}

extend Container {
    optional MyMessage testus = 1000;
}

I think it is even possible to do this without recompiling the main Machinetalk library. The calling code looks a little bit different:

from machinetalk.protobuf.message_pb2 import Container
import machinetalk.protobuf.types_pb1 as types
import machinetalk.protobuf.myprotocol_pb2 as pb

x = Container()
...
if (x.type == types.MT_REQ) and x.HasExtension(pb.testus):
    testus = x.Extension[pb.testus]
    if testus.type == pb.COOL_PING:
         print(testus.easy)

Looks pretty easy and keeps things in place.

machinekoder commented 8 years ago

However, the Extension type seems to breakable when a id is redefined and the type one the other side does not match the local type. It looks like this feature will be replaced in proto3 by the Any type which will bring type safety: https://developers.google.com/protocol-buffers/docs/proto3?hl=en#any