Google Protocol buffers?

[BlueIcaro]

Hello, is there any library or some code to use Google Protocol buffers in freepascal/lazarus?.

Thanks in advance

/Blueicaro

[Fabio Souza]

There are new components that use Google's api. Take a look at http://svn.freepascal.org/svn/lazarus/trunk/components/googleapis/

[BlueIcaro]

Thanks for our answer, but the google components that you point in, is for Google REST API, no for google protocol buffer.

/BlueIcaro

[taazz]

Thanks for our answer, but the google components that you point in, is for Google REST API, no for google protocol buffer.

/BlueIcaro

http://sourceforge.net/projects/protobuf-delphi/
http://fundementals.sourceforge.net/dl.html

two links in pascal not lazarus per see but a start for you.

[z505]

http://sourceforge.net/projects/protobuf-delphi/
http://fundementals.sourceforge.net/dl.html

two links in pascal not lazarus per see but a start for you.

Combine google protocol buffers with SimpleIPC, and you have a standard ipc mechanism instead of everyone rolling their own ipc system a million times...

Put simpleipc in a flat DLL with plain pascal/C functions, and google protocol buffer api wrapper, and now you have a standard IPC DLL anyone can put into their application, similar to a sqlite dll for lite sql use, now there can be "liteIPC" with maybe a second larger optional alternative DLL that uses AdvancedIPC and offers more features

This will be my todo project next coming days, then make website for it, like ZeroMQ

Standard apology for being thread necromancer

[piola]

This will be my todo project next coming days, then make website for it, like ZeroMQ

Could you publish/link the result, please?

[rossh_lz]

Adding another build for Protocol Buffer on Delphi and FPC

https://github.com/HHS-Software/Protocol-Buffer_Delphi_FPC

[Thaddy]

The google libs include an example on how to extract any of googles protocols. Why relying on the components? You can generate the newer API's yourself from that example code.

Don't expect, draw drop, paint screen: be a human: program, not screen draw.

[rossh_lz]

Why you ask?  One word: OOP.   

There is one main component with the read write code, which is the main part of PB.  Then every message has to have its own memory (a record or a class), and needs to uniquely get its data onto and off the wire.  With OOP, we have one generic read write, that any sub class inherits from and uses that generic read / write.    Furthermore, there is a lot of nested messages in nested messages in messages in PB, and often in different mixed up combinations.  This lends itself to classes and inheritance.
Doing this approach, we have two files total, and that is for hundreds of proto messages.  :-)

You don't like classes?  A class is just a record with a handful of functions and some tables of pointers attached, and automated memory allocations.  Not really that terrible.

If instead the messages were all stand alone records, then each message record needs its own read write code.  I started out this way, but it became an unmanageable mess when hundreds of .proto files are involved.

Speaking of messes.   The Google C++ supplied code requires / has hundreds of files compiled into the project, and this is a fine example of coding by committee.   It adds MB's to the project.   This is fine when server A talks to server B, but not for user applications.  No, we will not be using the Google system as an example, thank you.