Isolate actual protocol buffers serialization engine from the rest of the code.

[GoogleCodeExporter]

I would not be surprised if you have probably thought about it already.

I think, that any serialization may be regarded as consisting of two logical 
phases:
1. Convert the given object graph into a stream of serialization instructions.
2. Interpret the serialization instructions - i.e. produce the actual 
serialization result.

The challenge is to come up with a technology neutral serialization 
instructions, I call it the serialization byte code.

Then actual serialization engine can be viewed as the serialization runtime 
producing actual serialization result from the serialization byte code.

Thus:
 - the XML serialization runtime produces XML.
 - the JSON serialization runtime produces JSON.
 - the protocol buffers serialization runtime produces the protocol buffers output.

It seems to me that you have already done must of the work to accomplish this 
goal.

What is the point of it? The point is that protobuf-net supports advanced 
features like surrogates and shared references, which have little to do with 
protocol buffers, but have very much to do with serialization in general. 
However, protobuf-net "only" knows to serialize to protocol buffers. It is a 
shame to "subjugate" all the advanced features just to protocol buffers?

Does it make sense to you?

Original issue reported on code.google.com by mark.kha...@gmail.com on 13 Jul 2011 at 8:10

[GoogleCodeExporter]

I don't disagree, and it is something I've been playing with in my head for a 
while. There are some aspects of the current decorator tree that are highly 
related to protobuf, but perhaps a reasonable middle ground would be to 
construct subtly different trees for different scenarios (for example, the way 
lists are handled between xml and .proto would warrant a different decorator 
implementation there).

This would (in theory) allow me to use most of the "meta" and "emit" layers, 
and simply have a different reader/writer on the top, and perhaps a few minor 
tweaks in the tree.

It is on my roadmap, but I plan on clearing down my backlog before tackling 
this, as it is not without effort.

Original comment by marc.gravell on 13 Jul 2011 at 10:59

[GoogleCodeExporter]

I will be waiting for this development. It bears a great promise.
Thanks.

Original comment by mark.kha...@gmail.com on 13 Jul 2011 at 11:07

[GoogleCodeExporter]

Have a look at http://www.sharpserializer.com/en/index.html
It seems relevant.

Original comment by mark.kha...@gmail.com on 20 Sep 2011 at 6:20