[Mono-dev] Serialization strategies for compatibility.

[Lluis Sanchez]

El dl 05 de 06 del 2006 a les 00:42 -0400, en/na Miguel de Icaza va
escriure:
(snip)
>     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.

One problem of using Mono-specific hooks (or using 2.0 hooks in 1.1) is
that we can't force custom formatters to use those hooks, so we can't
guarantee that formatters other than BinaryFormatter or SoapFormatter
would be able to deserialize Color objects. We can implement this logic
in ObjectManager, which has a high probability of being used by custom
formatters, but it use is not mandatory.

> 
>     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?

The API would be different, but I don't see how this change could break
existing code.

Lluis.