View source for Explicit Object Serialization

= Proposal =

Up until now, when we've needed to serialize scene objects (for storage in inventory, movement over region borders, etc.), we've done so using .NET's automatic XML serialization capabilities (XmlSerializer).

.NET XML serialization is convenient when completely adding or removing properties - extraneous XML elements can be simply ignored and missing ones just result in the use of a default value. 

But if one wants to change an existing element then things get much more difficult. For instance, suppose that you want to change the existing UUID CreatorID of SceneObjectPart to be a string instead. Because the CreatorID uses OpenMetaverse's UUID object, .NET serialization of this produces the following

 <CreatorID><Guid>a6dacf01-4636-4bb9-8a97-30609438af9d</Guid></CreatorID>

Simply changing the CreatorID type to String in SceneObjectPart will cause .NET to look for

 <CreatorID>a6dacf01-4636-4bb9-8a97-30609438af9d</CreatorID>

on deserialization, making older assets incompatible. The alternative approach of adding a string CreatorID property alongside the existing UUID one (e.g. have both CreatorID and CreatorIDFull in SceneObjectPart) quickly runs into very nasty problems with keeping the fields in sync.

Therefore, I propose that for SceneObjectPart (and later TaskInventoryDictionary) we switch to explicit XML reading and writing rather than using .NET serialization. This will allow object serializations to evolve without adding increasingly odd code to keep automatic serialization working, if that's possible at all (we already have some nasty find and replace stuff in SceneObjectSerializer.FromOriginalXmlFormat()). Serialization formats will also gain explicit version numbers.

Other parts of scene object serialization, such as script state, will remain as they are now.

Being explicit about serialization may also promote interop and modularization. Explicit serialization can be moved away from core and into modules rather than requiring .NET XML serialization attributes on fields in SceneObjectPart.

Naturally, I expect that OpenSimulator out of the box will always be compatible with older serialization formats - migrating existing scene object assets is not realistically possible. Also, I propose that the behaviour when adding or removing scene object elements (as opposed to changing them) remain the same as it does with .NET serialization. In other words, older region simulators will able to read newer object serializations simply by ignoring the extra elements. Only changes to existing elements will require a region simulator upgrade and these should be rare.