[Mono-dev] Serialization strategies for compatibility.

[Miguel de Icaza]

Hello,

    Last week Gonzalo fixed some of the serialization for the "Color"
struct in Mono to enable serialization of certain objects for
Windows.Forms applications.   Some of the fixes are relatively
straightforward, these involved changing the internal representation to
match the MS implementation.

    But one change which was particularly annoying was one dealing with
the way that MS Color is serialized.  They have a concept of "Known
Colors", and if a flag in the serialization is set, the color is
initialized from a known color index.   

    The idea is fine, but mixed with serialization it means that we do
not get a chance to compute the color RGB values in advance, but have
instead to compute the values on demand, the first time the values are
accessed.   For the current code changes that we had to do, look for the
"R" property for example:

http://svn.myrealbox.com/viewcvs/trunk/mcs/class/System.Drawing/System.Drawing/Color.cs?rev=61426&view=auto

    Now, it is debatable whether optimizing Color is an issue at all,
but I ran into a new feature of the .NET Framework 2.0 that might help:
"Versioning Tolerance", the hacks are fairly simple and are described
here:

http://www.codeguru.com/csharp/.net/net_general/netframeworkclasses/article.php/c9297/

and here:

http://msdn2.microsoft.com/en-us/library/ms229752.aspx

    These particular hooks would allow us to implement a fast "Color",
for instance, we can use the [OnDeserialized] attribute and compute the
ARGB values as soon as the type has been de-serialized, avoiding
completely the ugly test that we currently have in place.

    Now, there are two problems:

	* It is only available in 2.0.

	* The new hooks do not cope well with differently-named fields.

    Since this stuff is genuinely useful, I was considering whether we
could make our 1.1 implementation support it, but to avoid exposing a
non-existent 1.1 type, we could do a name-based attribute lookup on the
methods and if we find that there is such an attribute, we could perform
the same tasks that 2.0 does.   This means that 1.1 assemblies could get
the 2.0 "hooks" by including their own copy of the attribute.   The only
issue here is whether this would not have a negative performance
impact.  

    The second issue is: how do we cope with deserialization in the
future without having to change our internals extensively?   And I think
that if we extend the serialization framework we can do this.

    We could introduce some *extra* attributes that are specific to
Mono, and that are applied to the type.  If such attribute is found, it
would instruct the deserializer to not perform the manual
deserialization/serialization, but instead use an ISerializable-like
approach on that given class, this would give us the control we need.

    Now in .NET 1.1 SP-N I noticed that they introduced some changes.
Some classes now implemented some new interfaces that were not present
in .NET 1.1.   My question is: what is the justification to add new
implemented interfaces to classes, and could we get away by just
sprinkling "ISerializable" on our classes, or would that be considered a
massive breach of API compatibility?    

Miguel.