> Over 2 years we haven't faced any compatibility issues. I agree there is always the possibility when writing your own compiler. On the other hand > PHP Protobuf is not dependant on the original Protocol Buffers implementation.
please check https://developers.google.com/protocol-buffers/docs/reference/other . We should not provide own .proto compiler. we should provide as compiler plugin. Many developers who uses other programming language uses `protoc` compiler to generate PB messages. We should follow the way. > What does a switch from hash to object properties give us? I'm not sure whether I what you mean by "wakeup" and "sleep". Currently, your extension uses `values` property to store each fields. We can easily to add `__wakeup` and `__sleep` methods if we switch this to each properties. But I don't know this is good for protocol buffers implementation. At least some existing binary serialization extension (Messagepack, Mongo's bson) supports `__wakeup` and `__sleep` method. probably many php developer wants this feature. > PHP-specific proto options are definitely nice-to-have feature:) Yea, i think so :) currently, PHPOptions reserved 1004. https://groups.google.com/forum/?fromgroups#!topic/protobuf/--s0Zsjx5eY > I really don't see any drawbacks of extending from ProtobufMessage class. May you elaborate more on that? let's assume every PB message should have `getDescriptor` method. then we can keep PB message class as very simple (nearly POPO). You can inherit any class you want. you can create dynamic PB messages (this feature need Descriptor class.) ... also you can easily to stop using protocol buffers. Customary, extending ProtobufMessage is good way. but we should have other choices. > Have you found any TSMRLS compile errors? May you send them to me or tell me how to reproduce them? did you test with --enable-maintainer-zts? I can't compile your extension with zts mode PHP. http://php.net/manual/en/internals2.buildsys.environment.php > PHP Protobuf has been used for over two years with success. Its working solution and I believe making any changes should be well justified. Any change comes with risk of breaking working code. Yea, I think so. I respect your working codes. we should have more test cases. bad problem is storing wrong data, afraid to change existing code. By the way, do you have a road map to support repeated packed attributes, Extension and some not implemented PB features? -- Additionally, I found string problem. protocol buffers must check string field contains utf8 encoded or 7-bit ascii text. could you add it? https://github.com/allegro/php-protobuf/blob/master/protobuf.c#L923 https://developers.google.com/protocol-buffers/docs/proto (see Scalar Value Types section) On Thu, May 23, 2013 at 3:15 PM, hubert.jagodzinski < [email protected]> wrote: > On 22.05.2013, at 13:56, chobie wrote: > > Hi > > I'm also working protocolbuffers extension here. Unfortunately same > timing :-( > > https://github.com/chobie/php-protocolbuffers > > cullently, my impl is too messy. It started about 2 weeks ago:-/ > > > We should consider about interface, architecture beofore publishing > it as PECL extension. Let's talk about those things. > > We have some issues about pb. > * we should provide protoc plugin. Don't use own parser. > keeping .proto file parser is bad things I think. It's hard to keep > compatibility. > * we should use object property instead of single hash. > This is more straightforward and easy to add wakeup and sleep method. > * consider about php.proto options > There are several pure php implementation. So we should ask them before > decide it. > * consider about interface. I recommend do not inherit protobufmessage > class as We should not force class hieralcy. > we can easily to add getter, setter methods with protoc. > * fix TSMRLS compile error (small things) > > I'm happy to hear your announce but consider about architecture as PB > has very big advantage than other serialization. > > Thanks, > Shuhei > > On Wednesday, May 22, 2013, hubert.jagodzinski wrote: > >> Hi, >> >> my name is Hubert Jagodziński. I work as a senior developer in the >> biggest e-commerce company in East-Central Europe - Allegro Group. >> >> We have found Protocol Buffers [1] quite interesting in RPC protocol. >> Unfortunately existing PHP implementations were not very efficient so >> decision to implement our own as extension was made. >> >> We decided to share our project with open source community. Its name is >> PHP Protobuf and you can find it here [2]. >> >> May I request for an account at pecl.php.net so I can publish this >> project here? >> >> [1] http://code.google.com/p/protobuf >> [2] https://github.com/allegro/php-protobuf >> >> regards, >> >> -- >> Hubert Jagodzinski >> Zespół Rozwiązań Backendowych >> Zespół Allegro >> http://www.allegro.pl >> >> Grupa Allegro Sp. z o.o. z siedzibą w Poznaniu, 60-166 Poznań, przy ul. >> Grunwaldzkiej 182, wpisana do rejestru przedsiębiorców prowadzonego przez >> Sąd Rejonowy Poznań - Nowe Miasto i Wilda, Wydział VIII Gospodarczy >> Krajowego Rejestru Sądowego pod numerem KRS 0000268796, o kapitale >> zakładowym w wysokości 33 474 500 zł, posiadająca numer identyfikacji >> podatkowej NIP: 5272525995. >> >> >> -- >> PECL development discussion Mailing List (http://pecl.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > Project was created over 2 years ago. Unfortunately at the time publishing > as an open source was not possible at my company:( > > Over 2 years we haven't faced any compatibility issues. I agree there is > always the possibility when writing your own compiler. On the other hand > PHP Protobuf is not dependant on the original Protocol Buffers > implementation. > > What does a switch from hash to object properties give us? I'm not sure > whether I what you mean by "wakeup" and "sleep". > > PHP-specific proto options are definitely nice-to-have feature:) > > I really don't see any drawbacks of extending from ProtobufMessage class. > May you elaborate more on that? > > Have you found any TSMRLS compile errors? May you send them to me or tell > me how to reproduce them? > > PHP Protobuf has been used for over two years with success. Its working > solution and I believe making any changes should be well justified. Any > change comes with risk of breaking working code. > > regards, > > -- > Hubert Jagodzinski > >
