views:

262

answers:

1

I started looking at using proto-buf .Net for my serialization needs for media browser.

In the new system we have a entity framework that can be extended with plug-ins.

So, for example, we define a Media class in the core library, and then plug-ins can define subclasses such as Song.

It seems that proto-buf .Net needs to know about all sub types of our core defined base class.

So I am expected to decorate my base class with

[ProtoInclude(2, typeof(Song))]

But ... at that point in time I know nothing about the Song class that does not exist yet.

Is it back to the drawing board? Am I trying to do something the library is not designed for?

+1  A: 

(from the author)

In the current release, it is fixed to types known to the parent. However, this is a known limitation, so there is a plan to abstract the meta-model so that it can be provided separately at runtime - broadly comparable to how you provide such information to XmlSerializer (it will still need a way to provide tags (the "2" above) per type).

I have started on this work, but I expect it to take a few weeks to get it fully working (the refactor will also tie into some other changes to help compact framework).

So up to you... if you can wait a few weeks, I hope to have something working.

Note that you would still need some way of generating (unique, repeatable) tags for all the different sub-types - configuration, etc.

Marc Gravell
This is of course the correct answer to the question :)
Sam Saffron
I have managed to get my current serialization implementation to support my limited needs. http://code.google.com/p/videobrowser/source/browse/branches/big_refactor/TestMediaBrowser/TestSerialization.cs
Sam Saffron
Later down the line when I you are done, I'll see if I port the stuff over to use protobuf. Jeez stuff gets complex when you support inheritance chains of properties ...
Sam Saffron
With the unique tags .. could you not default to the typename if nothing is specified?
Sam Saffron
Indeed. Especially if the binary format (defined by Google) doesn't actually include inheritance! It already uses some clever tricks simply to achieve inheritance while retaining wire-compatibility...
Marc Gravell
No; they have to be integers to fit into the wire format. Or I'd need to think of an *even more clever* way of spoofing it. Plus, the type name is an implementation detail, where-as the wire-format is contract based - i.e. you can use different types (that match at the contract level).
Marc Gravell
hmmm.... I could probably do it by including (against a magic-number tag) the fqn / aqn of the type *at the parent*, and working backwards... breaks some purist rules, but doable. Maybe. I'd rather do the dynamic metadata thing, though.
Marc Gravell