My (informal) thoughts... First; it should be noted that this isn't unique to pb; a number of other serialization engines use very similar tricks.
Ultimately, it is as simple as, when encountering unexpected data, storing the unexpected data (unprocessed) against the entity. This allows it to round-trip such an object without dropping anything, by including this data during serialization. The other common approach is to silently drop unexpected data - which allows it to deserialize, but when next serialized (to round-trip) the unexpected fields will be lost. Depending on the implementation, there is also no reason why this extra data can't be queried at runtime, as long as the caller supplies the necessary additional information (descriptors etc) to tell it how to decode it - so even though it wasn't in the schema (.proto) when the DTOs were generated, it can still potentially be available for ad- hoc query. In the case of pb, this involves storing the binary - so if it sees [tag 7, string][length][data x length], it will store that much data as a block of bytes, and then move onto the next field. You mention comparison to xml; picking .NET's XmlSerializer as an example, you can (optionally) include (on your DTO) some special collection properties marked with the attributes [XmlAnyAttribute] / [XmlAnyElement]; if it encounters an xml attribute it couldn't map to the object, it stores it in the first - and any unexpected xml elements go into the second. During serialization, those items are appended. The related (but different) DataContractSerializer uses the IExtensibleDataObject interface (and the ExtensionData property) for similar purposes. I would hope and imagine that similar serializers in java etc have similar forwards-compatible hooks. Marc Gravell On Jun 11, 4:09 am, Alain Mouette <ala...@pobox.com> wrote: > Yes I have google a few times, but nothing that I got was usefull :( > > What I want to understand more is this: The way PB is constructed, an > old SW can talk to an newer SW and they can get along using only what > they understand, with little extra programing. > > That per-se is probably close to what is called backward-and-forward > compatibility. > > Just an example, if you plug a new SATA2 drive in an older machine and > it works, the other way around too. (It uses a serial protocol too) > > What I want is to study what is behind those nice tricks. > > thanks for your attention, > Alain > > Alek Storm escreveu: > > > > > Could you clarify a little more? I'd be happy to help, but you have > > tried Googling this, right? > > > On Mon, Jun 8, 2009 at 6:54 PM, Alain M. <ala...@pobox.com > > <mailto:ala...@pobox.com>> wrote: > > > Hi, > > > One of the big advantages of ProtBuf is the ability to make > > comunications Forward *and* backward compatible beween versions. > > > I would like to study the matter a little more, preferably not directly > > related to PB, but in a neutral background (even XML could be). > > > Can enyone send some reference about this topic? > > > Thanks, > > Alain Mouette > > > -- > > Alek Storm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---
