StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Some performance and size metrics are on <a href="http://code.google.com/p/protobuf-net/wiki/Performance" rel="noreferrer">this page</a>. I haven't got Jon's stats on there at the moment, just because the page is a little old (Jon: we must fix that!).</p> <p>Re being transparent; <a href="http://code.google.com/p/protobuf-net/" rel="noreferrer">protobuf-net</a> can hook into WCF via the contract; note that it plays nicely with MTOM over basic-http too. This doesn't work with Silverlight, though, since Silverlight lacks the injection point. If you use svcutil, you also need to add an attribute to class (via a partial class).</p> <p>Re BinaryFormatter (remoting); yes, this has full supprt; you can do this simply by a trivial <code>ISerializable</code> implementation (i.e. just call the <code>Serializer</code> method with the same args). If you use <code>protogen</code> to create your classes, then it can do it for you: you can enable this at the command line via arguments (it isn't enabled by default as <code>BinaryFormatter</code> doesn't work on all frameworks [CF, etc]).</p> <p>Note that for very small objects (single instances, etc) on local remoting (IPC), the raw <code>BinaryFormatter</code> performance is actually better - but for non-trivial graphs or remote links (network remoting) protobuf-net can out-perform it pretty well.</p> <p>I should also note that the protocol buffers wire format doesn't directly support inheritance; protobuf-net can spoof this (while retaining wire-compatibility), but like with XmlSerializer, you need to declare the sub-classes up-front.</p> <hr> <h2>Why are there two versions?</h2> <p>The joys of open source, I guess ;-p Jon and I have worked on joint projects before, and have discussed merging these two, but the fact is that they target two different scenarios:</p> <ul> <li><a href="http://github.com/jskeet/dotnet-protobufs/tree/master" rel="noreferrer">dotnet-protobufs</a> (Jon's) is a port of the existing java version. This means it has a very familiar API for anybody already using the java version, and it is built on typical java constructs (builder classes, immutable data classes, etc) - with a few C# twists.</li> <li><a href="http://code.google.com/p/protobuf-net/" rel="noreferrer">protobuf-net</a> (Marc's) is a ground-up re-implementation following the same binary format (indeed, a critical requirement is that you can interchange data between different formats), but using typical .NET idioms: <ul> <li>mutable data classes (no builders)</li> <li>the serialization member specifics are expressed in attributes (comparable to <code>XmlSerializer</code>, <code>DataContractSerializer</code>, etc)</li> </ul></li> </ul> <p>If you are working on java and .NET clients, Jon's is probably a good choice for the familiar API on both sides. If you are pure .NET, protobuf-net has advantages - the familiar .NET style API, but also:</p> <ul> <li>you aren't <em>forced</em> to be contract-first (although you can, and a code-generator is supplied)</li> <li>you can re-use your existing objects (in fact, <code>[DataContract]</code> and <code>[XmlType]</code> classes can often be used without any changes at all)</li> <li>it has full support for inheritance (which it achieves on the wire by spoofing encapsulation) (possibly unique for a protocol buffers implementation? note that sub-classes have to be declared in advance)</li> <li>it goes out of its way to plug into and exploit core .NET tools (<code>BinaryFormatter</code>, <code>XmlSerializer</code>, WCF, <code>DataContractSerializer</code>) - allowing it to work directly as a remoting engine. This would presumably be quite a big split from the main java trunk for Jon's port.</li> </ul> <p>Re merging them; I think we'd both be open to it, but it seems unlikely you'd want both feature sets, since they target such different requirements.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload