2014/1/2 Shuhei Tanuma (chobie) <[email protected]>:
> Hi, I’d like to advance discussion about proposing PECL protocol
> buffers as half a year has passed since last discussion.
>
>
> Last year, I was stopped my and allegro's protocol buffers proposing
> as both implementations are not enough to publish.
> (for example, lacks protobuf specs,  protoc plugin support and less
> test cases.).
>
> [protocol buffers extensions]
> https://github.com/chobie/php-protocolbuffers
> https://github.com/allegro/php-protobuf
>
> [previous discussions]
> http://marc.info/?l=pecl-dev&m=136921051809419&w=2
>
> Here is the current summary of both extensions:
>
> |                       | chobie/php-protocolbuffers | allegro/php-protobuf |
> | --------------------- | -------------------------- | -------------------- |
> | LICENSE               | New BSD License            | New BSD License      |
> | Standard Types*       | Supported                  | Supported            |
> | Repeated Fields*      | Supported                  | Supported            |
> | Packed attributes*    | Supported                  | Not Supported        |
> | protoc generator      | PHP + extension            | original parser      |
> | Extensions            | Supported                  | Not Supported        |
> | Unknown fields        | Supported                  | Not Supported        |
> | RPC                   | Not Supported              | Not Supported        |
> | external dependencies | None (protoc [2])          | None                 |
> | Windows support       | Supported                  | Not Supported        |
>
> NOTE: * marks are at least requires current protocol buffers spec.
>
> Allegro’s  implementation still lacks some important features.
> Especially, packed attribute and using original proto parser causes
> problems with some complicated proto files:
>
> For example, one of the famous proto file `Google’s DoubleClick Ad
> Exchange Real-Time Bidding Protocol`[1] uses packed attributes and
> complicated proto file. Unfortunately, their extension can’t parse
> that protocol buffers message.
>
>
> I think easiest conclusion is accept both implementations.
> (Although, I never said `+1` their propose till they implemented
> packed attribute and protoc plugin. it’s important features in
> protocol buffers.)
>
> If we can’t choose that opinion, Starting my extension is the easiest way.
> Because It already has most protocol buffers features. and It design
> inspired original java and c++. following new features is not tough.
>
>
> We want to get feedback about this topic.
>
> Thanks,
> Shuhei
>
> [References]:
> protocol buffers
> https://code.google.com/p/protobuf/
> [1] Google’s DoubleClick Ad Exchange Real-Time Bidding Protocol
> https://developers.google.com/ad-exchange/rtb/downloads/realtime-bidding-proto.txt
> [2] requires protoc compiler when generating messages
> https://developers.google.com/protocol-buffers/docs/cpptutorial (see
> Compiling Your Protocol Buffers section)

It seems no negative feedbacks. I'll do some stuff and upload package
in a few days.

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to