[Opensim-dev] RFC/Proposal: Explicitly serializing SOP rather than relying on .NET automatic serialization.

[Justin Clark-Casey]

Frisby, Adam wrote:
> Speak with Mikko - he wrote a manual parser that reads our formats. We needed it at the time for ModRex.
> 

Thanks Adam, I will contact Mikko.

> Overall however +1 on a explicit serialisation. Please leave some room to allow us to tag metadata in too.

Just to be clear, explicit serialization will match exactly what is currently being done by the .NET XmlSerializer, 
including its tolerance for missing or extraneous XML elements.  This proposal is about making evolution possible rather 
than actually doing it.

> 
> Adam
> 
>> -----Original Message-----
>> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
>> bounces at lists.berlios.de] On Behalf Of Justin Clark-Casey
>> Sent: Tuesday, 9 June 2009 9:04 AM
>> To: opensim-dev at lists.berlios.de
>> Subject: [Opensim-dev] RFC/Proposal: Explicitly serializing SOP rather
>> than relying on .NET automatic serialization.
>>
>> Hi there,
>>
>> (For reference, I've reproduced this rfc at
>> http://opensimulator.org/wiki/Explicit_Object_Serialization but any
>> comments
>> can be made here).
>>
>>
>> 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 OpenSim 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.
>>
>> Comments?
>>
>> --
>> justincc
>> Justin Clark-Casey
>> http://justincc.wordpress.com
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 


-- 
justincc
Justin Clark-Casey
http://justincc.wordpress.com