On Thu, Dec 11, 2014 at 12:02 PM, Michael Haberler <mai...@mah.priv.at>
wrote:
>
> Hallo Feng,
>
>
> > Am 11.12.2014 um 05:51 schrieb Feng Xiao <xiaof...@google.com>:
> >
> > 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?
>
+liujisi, who is more qualified to answer this than me.
I think your reading is correct. We'll publish an protobuf implementation
for node.js but not for the Javascript language in general (like the
ProtoBuf.js you linked), while JSON format support will be added to all
protobuf implementations. Web apps would talk JSON to its server although
the server can support both JSON format and protobuf wire format.
As far I know, protobuf wire format does not have much of an advantage over
JSON format on web apps because the payload is usually small enough and
encoding/decoding protobuf wire format with Javascript does not necessarily
have a better performance than the built-in JSON encoder/decoder. As most
web apps are already using JSON as the data exchange format, supporting
JSON format on the sever side so it can talk with JSON clients seems a
natural choice here.
>
> 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 protobuf+unsubscr...@googlegroups.com.
> > To post to this group, send email to protobuf@googlegroups.com.
> > 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 protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
