On Jul 21, 3:57 am, Tim Acheson tim.ache...@gmail.com wrote:
I generally create web services using WCF or ASP.NET MVC. I don't get
the point of Protocol Buffers. Am I missing something?
It'd be a similar set of reasons as to why we abandoned XML and JSON
in favor of AMF when marshaling i/o
On Jul 21, 10:57 pm, Tim Acheson tim.ache...@gmail.com wrote:
I generally create web services using WCF or ASP.NET MVC. I don't get
the point of Protocol Buffers. Am I missing something?
snip
I don't need to write any code to do the serialisation, either. I just
define the return type of
And of course, if you *are* happy using WCF and .NET, with all the
simplicity that provides, you can *still* use protobuf, since protobuf-net
includes a WCF hook that (if you desire) swaps-out the serializer used by
WCF. So your *existing* .NET code (bereft of any .proto definition) can
enjoy
There is also the other end of the spectrum, where I am at. With a
large Hadoop cluster and terabytes of data, the efficient storage and
zippy parsing of protobufs is a huge deal.
In many ways, protobufs allow you do do what XML promised, but much
more efficiently. The other way to look at them
Christopher Smith wrote:
There is also the other end of the spectrum, where I am at. With a
large Hadoop cluster and terabytes of data, the efficient storage and
zippy parsing of protobufs is a huge deal.
In many ways, protobufs allow you do do what XML promised, but much
more efficiently.
On Sat, Jul 24, 2010 at 3:22 PM, Oliver Jowett oliver.jow...@gmail.comwrote:
Christopher Smith wrote:
There is also the other end of the spectrum, where I am at. With a
large Hadoop cluster and terabytes of data, the efficient storage and
zippy parsing of protobufs is a huge deal.
In
3. Schema evolution supported out-of-the-box (backward compatibility)
4. Also, because of the schema, protobufs are strongly typesafe, and
JSON is not.
5. Using the APIs makes programs easier to understand and debug,
versus libraries that support object serialization as an afterthought,
The consensus seems to be that the main rationale for Protocol Buffers
is cross-platform interoperability, and transferring objects between
platforms.
I can already consume JSON objects from a WCF service using JavaScript
in the web browser. I can see that if I used other platforms/languages
I
On Thu, Jul 22, 2010 at 3:01 AM, Tim Acheson tim.ache...@gmail.com wrote:
The consensus seems to be that the main rationale for Protocol Buffers
is cross-platform interoperability, and transferring objects between
platforms.
I can already consume JSON objects from a WCF service using
If you can show me a format which offers faster serialisation or
deserialisation than JSON in a .NET application, I'd be impressed! :)
Although I haven't heard anybody experiencing problems with the
performance of either direction in .NET with JSON or XML, the
libraries provided by the framework
On Thu, Jul 22, 2010 at 07:50, Tim Acheson tim.ache...@gmail.com wrote:
If you can show me a format which offers faster serialisation or
deserialisation than JSON in a .NET application, I'd be impressed! :)
If the speed and size of JSON serialization is good enough for you,
stick with it.
If you can show me a format which offers faster serialisation or
deserialisation
than JSON in a .NET application, I'd be impressed! :)
In .NET? Sure: vs which json engine? I'm pretty certain that protobuf-net
(especially v2, but probably v1) can thrash it.
This is v1, which is quite a bit
12 matches
Mail list logo
