Explicit Object Serialization
From OpenSimulator
m (Robot: Cosmetic changes) |
|||
| Line 4: | Line 4: | ||
{{proposal}} | {{proposal}} | ||
| − | =Status= | + | = Status = |
Done! | Done! | ||
| − | =Introduction= | + | = Introduction = |
'''Proposer:''' Justin Clark-Casey (justincc) | '''Proposer:''' Justin Clark-Casey (justincc) | ||
| Line 16: | Line 16: | ||
'''Closing date for this proposal:''' 12th June 2009 | '''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). | 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. | + | .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. | + | 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> | <CreatorID><Guid>a6dacf01-4636-4bb9-8a97-30609438af9d</Guid></CreatorID> | ||
| Line 30: | Line 30: | ||
<CreatorID>a6dacf01-4636-4bb9-8a97-30609438af9d</CreatorID> | <CreatorID>a6dacf01-4636-4bb9-8a97-30609438af9d</CreatorID> | ||
| − | on deserialization, making older assets incompatible. | + | 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. | + | 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. | 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. | + | 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. | + | 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. |
Revision as of 19:01, 3 March 2012
 |
Languages: |
|
|
|
This article or section is a Proposal It does not represent the current state of OpenSim, but is an idea for future work in OpenSim. Please feel free to update this page as part of the proposal discussion. |
Status
Done!
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.
