Hallo Feng,
> Am 11.12.2014 um 05:51 schrieb Feng Xiao <[email protected]>: > > Hi all, > > I just published protobuf v3.0.0-alpha-1 on our github site: > https://github.com/google/protobuf/releases/tag/v3.0.0-alpha-1 a question on structuring web applications further downstream: you mention node.js and JSON (de)serialisation reading between the lines this would suggest to me a typical protobuf application talking to a web client would talk JSON-serialized protobuf (maybe over a websocket stream) I've used this scheme and while JSON is easy for browser js engines, there are downsides; for instance, (de)serializing doubles from/to JSON usually creates conversion/rounding fuzz - that precludes signing a protobuf object in binary representation because the signature generally wont be valid after JSON conversion. Looser type checking is another drawback. That is why I found an end-to-end binary protobuf transfer and client-side js bindings along the lines of https://github.com/dcodeIO/ProtoBuf.js more robust what's the grand vision here - how are web apps going to talk to protobuf API's server-side? thanks in advance, Michael > > This is the first alpha release of protobuf v3.0.0. In protobuf v3.0.0, we > will add a new protobuf language version (aka proto3) and support a wider > range of programming languages (to name a few: ruby, php, node.js, > objective-c). This alpha version contains C++ and Java implementation with > partial proto3 support (see below for details). In future releases we will > add support for more programming languages and implement the full proto3 > feature set. Besides proto3, this alpha version also includes two other new > features: map fields and arena allocation. They are implemented for both > proto3 and the old protobuf language version (aka proto2). > > We are currently working on the documentation of these new features and when > it's ready it will be updated to our protobuf developer guide. For the time > being if you have any questions regarding proto3 or other new features, > please post your question in the discussion group. > > CHANGS > ======= > Version 3.0.0-alpha-1 (C++/Java): > > General > * Introduced Protocol Buffers language version 3 (aka proto3). > > When protobuf was initially opensourced it implemented Protocol Buffers > language version 2 (aka proto2), which is why the version number > started from v2.0.0. From v3.0.0, a new language version (proto3) is > introduced while the old version (proto2) will continue to be supported. > > The main intent of introducing proto3 is to clean up protobuf before > pushing the language as the foundation of Google's new API platform. > In proto3, the language is simplified, both for ease of use and to > make it available in a wider range of programming languages. At the > same time a few features are added to better support common idioms > found in APIs. > > The following are the main new features in language version 3: > > 1. Removal of field presence logic for primitive value fields, removal > of required fields, and removal of default values. This makes proto3 > significantly easier to implement with open struct representations, > as in languages like Android Java, Objective C, or Go. > 2. Removal of unknown fields. > 3. Removal of extensions, which are instead replaced by a new standard > type called Any. > 4. Fix semantics for unknown enum values. > 5. Addition of maps. > 6. Addition of a small set of standard types for representation of time, > dynamic data, etc. > 7. A well-defined encoding in JSON as an alternative to binary proto > encoding. > > This release (v3.0.0-alpha-1) includes partial proto3 support for C++ and > Java. Items 6 (well-known types) and 7 (JSON format) in the above feature > list are not implemented. > > A new notion "syntax" is introduced to specify whether a .proto file > uses proto2 or proto3: > > // foo.proto > syntax = "proto3"; > message Bar {...} > > If omitted, the protocol compiler will generate a warning and "proto2" > will > be used as the default. This warning will be turned into an error in a > future release. > > We recommend that new Protocol Buffers users use proto3. However, we do > not > generally recommend that existing users migrate from proto2 from proto3 > due > to API incompatibility, and we will continue to support proto2 for a long > time. > > * Added support for map fields (implemented in C++/Java for both proto2 and > proto3). > > Map fields can be declared using the following syntax: > > message Foo { > map<string, string> values = 1; > } > > Data of a map field will be stored in memory as an unordered map and it > can be accessed through generated accessors. > > C++ > * Added arena allocation support (for both proto2 and proto3). > > Profiling shows memory allocation and deallocation constitutes a > significant > fraction of CPU-time spent in protobuf code and arena allocation is a > technique introduced to reduce this cost. With arena allocation, new > objects will be allocated from a large piece of preallocated memory and > deallocation of these objects is almost free. Early adoption shows 20% to > 50% improvement in some Google binaries. > > To enable arena support, add the following option to your .proto file: > > option cc_enable_arenas = true; > > Protocol compiler will generate additional code to make the generated > message classes work with arenas. This does not change the existing API > of protobuf messages and does not affect wire format. Your existing code > should continue to work after adding this option. In the future we will > make this option enabled by default. > > To actually take advantage of arena allocation, you need to use the arena > APIs when creating messages. A quick example of using the arena API: > > { > google::protobuf::Arena arena; > // Allocate a protobuf message in the arena. > MyMessage* message = Arena::CreateMessage<MyMessage>(&arena); > // All submessages will be allocated in the same arena. > if (!message->ParseFromString(data)) { > // Deal with malformed input data. > } > // Must not delete the message here. It will be deleted automatically > // when the arena is destroyed. > } > > Currently arena does not work with map fields. Enabling arena in a .proto > file containing map fields will result in compile errors in the generated > code. This will be addressed in a future release. > ======= > > Thanks, > Feng > > -- > You received this message because you are subscribed to the Google Groups > "Protocol Buffers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/protobuf. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
