Google Protocol Buffers
in [TCL]
|
Prev: Tk8.6, tile, png images and transparency
Next: Using Expect to automate file transers through Telnet with YMODEM...
From: nedbrek on 1 Jun 2010 06:55 Hello all, "tom.rmadilo" <tom.rmadilo(a)gmail.com> wrote in message news:ee6d7531-5d94-4fb4-a11e-3f4df4a9d955(a)g1g2000pro.googlegroups.com... > On May 28, 6:29 am, "nedbrek" <nedb...(a)yahoo.com> wrote: >> Hello all, >> I am trying to decode Google Protocol Buffers from inside Tcl. (The data >> format spec >> ishttp://code.google.com/apis/protocolbuffers/docs/encoding.html) >> >> First, I am looking at decoding the varint (which is the key to most >> stuff). > > Is this really the extent of your interest? This protocolbuffers thing > seems totally useless in Tcl since you would have to compile > the .proto file for a service and provide, or create an interface to > the library code provided by Google. Assuming you use their library, > you should not need to encode/decode anything, which is the whole > point of their scheme: create a compressed wire format for structured > data. I have a simple Tcl/Tk program which is really helpful for debugging. I will post it later... it dumps the key/value pairs generated by a complicated C++ program on the network. > Given the short history of this project, I would suggest creating a > Tcl interface to the C++ library so you can more easily pick up > changes...maybe look into using incrTcl. That is a possibility. I was hoping for pure Tcl solutions... > The project concept is against the current trend to hide internal > program data structures, types and API, but is obviously optimized for > bandwidth minimization and parsing speed reduction. I don't think that > they will ultimately achieve protocol and type safety since it is > allowed to include additional structure members and the order isn't > defined...it could be different on different platforms. The data is > also not self describing, so it doesn't solve the ultimate problem of > persistent storage. One of my personal projects uses XML. Anything is better than XML :) Although tdom is great. Ned
From: tom.rmadilo on 1 Jun 2010 11:24
On Jun 1, 3:55 am, "nedbrek" <nedb...(a)yahoo.com> wrote: > "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote in message > > The project concept is against the current trend to hide internal > > program data structures, types and API, but is obviously optimized for > > bandwidth minimization and parsing speed reduction. I don't think that > > they will ultimately achieve protocol and type safety since it is > > allowed to include additional structure members and the order isn't > > defined...it could be different on different platforms. The data is > > also not self describing, so it doesn't solve the ultimate problem of > > persistent storage. > > One of my personal projects uses XML. Anything is better than XML :) > Although tdom is great. Yeah, I would agree if tdom didn't exist or if I was using some other programming language which made auto-generated RPC attractive. I invented Rmadilo as my "binary XML" format, even simpler than protocol buffers, but of course it has nothing to do with network activity. However, it is easy to "decode" Rmadilo since there is no encoding. Like protocol buffers, applications would have to agree on the structure and meaning of a message, but there is no obfuscation/ compression involved: http://rmadilo.com/files/rmadilo/ I have one application for storing SQL data which does demonstrate a different type of compression: replacing column names with numbers, similar to what protocol buffers does for enumerations. It also can set defaults for missing columns. Another similarity to protocol buffers is that all structures are named, but all data is stored in attributes. The compiled format does not require char-by-char parsing and allows storage of arbitrary binary data. |