Explicit Object Serialization - Revision history

MakoBot: Robot: Replacing 'OpenSim' to 'OpenSimulator', which is the precise name

2012-03-04T06:22:25Z

Robot: Replacing 'OpenSim' to 'OpenSimulator', which is the precise name

MakoBot: Robot: Cosmetic changes

2012-03-04T03:01:01Z

Robot: Cosmetic changes

Justincc at 22:07, 5 October 2011

2011-10-05T22:07:14Z

MakoBot: Removed 'Template:' prefix from template includings and/or changed external-link into internal-link

2011-06-10T14:24:01Z

Removed 'Template:' prefix from template includings and/or changed external-link into internal-link

Justincc: New page: NOTOC {{Template:Quicklinks}} {{proposal}} =Introduction= '''Proposer:''' Justin Clark-Casey (justincc) '''Proposal Version:''' 0.1 '''Closing date for this proposal:''' 12th June...

2009-06-09T15:41:54Z

New page: __NOTOC__ {{Template:Quicklinks}} {{proposal}} =Introduction= '''Proposer:''' Justin Clark-Casey (justincc) '''Proposal Version:''' 0.1 '''Closing date for this proposal:''' 12th June...

New page

__NOTOC__
{{Template:Quicklinks}}

{{proposal}}

=Introduction=

'''Proposer:''' Justin Clark-Casey (justincc)

'''Proposal Version:''' 0.1

'''Closing date for this proposal:''' 12th June 2009

=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 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.

← Older revision		Revision as of 06:22, 4 March 2012
Line 38:		Line 38:
	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.		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.	+	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.

← Older revision		Revision as of 22:07, 5 October 2011
Line 3:		Line 3:

	{{proposal}}		{{proposal}}
		+
		+	=Status=
		+
		+	Done!

	=Introduction=		=Introduction=

@@ Line 4: / Line 4: @@
 {{proposal}}
-=Status=
+= Status =
 Done!
-=Introduction=
+= Introduction =
 '''Proposer:''' Justin Clark-Casey (justincc)
@@ Line 16: / Line 16: @@
 '''Closing date for this proposal:''' 12th June 2009
-=Proposal=
+= 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
+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>
@@ Line 30: / Line 30: @@
   <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.
+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.
+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.
+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.
+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.