[Mono-devel-list] un-interoperatible classes .NET -> Monoremoting

Jonathan Gilbert 2a5gjx302 at sneakemail.com
Wed Sep 29 18:46:55 EDT 2004


This wouldn't work as far as interoperability with existing code running
under MS.NET is concerned. However, as I see it, only one translator is
needed; the mono side could translate the binary format of specific classes
on a per-case basis to be compatible with MS.NET. I actually made this
suggestion years ago, but it was poo-pooed for some reason.

As for maintaining compatibility with older versions of mono, I don't know
whether there is any way to detect whether you're talking to mono remoting
on the other end, but if there is, the translation layer could be disabled
when mono is found (or even given multiple modes, to maintain the maximum
level of compatibility between different versions of mono as well as
mono<->MS, in the case that a future version of mono decides to change its
internal representation for a commonly-serialized runtime class).

Jonathan Gilbert

At 12:31 PM 28/09/2004 +0100, you wrote:
>As an alternative to compatibility problems, you could write two middle
>layers - one for each platform.  MonoLayer will translate to and from a
>Mono implementation to your new common implementation, and MSLayer will
>do the same, but for MS implementations.
>
>They will most likely be quite lightweight classes...
>
>Check out the Data Transfer Object pattern in Martin Fowler's "Patterns
>of Enterprise Application Architecture"
>
>Regards,
>Jason King
>Co-Author, "Cross-Platform .NET Development: Using Mono, Portable.NET,
>and Microsoft .NET" 
>(Apress, 2004, ISBN: 1-59059-330-8)
>http://www.cross-platform.net
>
>
>
>-----Original Message-----
>From: mono-devel-list-admin at lists.ximian.com
>[mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of Lluis
>Sanchez
>Sent: 28 September 2004 12:20
>To: Aleksandar Dezelin
>Cc: Mono-devel-list
>Subject: Re: [Mono-devel-list] un-interoperatible classes .NET ->
>Monoremoting
>
>
>On dt, 2004-09-28 at 03:52 -0700, Aleksandar Dezelin wrote:
>> Lluis Sanchez wrote:
>> 
>> >Only objects whose internal structure is identical in MS.NET and Mono
>
>> >(i.e. they have the same private fields with the same names) are 
>> >interoperable. The reason is that remoting sends a full copy of the 
>> >object and if the receiver expects a different structure for a type 
>> >it will fail. Classes in System.Collections have been gradually 
>> >modified to match those in MS.NET. Other classes may fail.
>> >
>> >Lluis.
>> >
>> 
>> Then System.Collections and it's classes including Hashtable are 
>> interoperable? Is there any kind of list of non-interoperable classes?
>
>No, there isn't such a list. Remoting interoperability between different
>CLR implementations is not guaranteed. Some classes that may be
>interoperable nowadays, may change its internal structure in the future
>and break that compatibility. For example, if you find that the class
>CultureInfo is not compatible with MS.NET, we can change it to make it
>compatible, but then we will break interoperability with old mono
>versions.
>
>If interoperability is important to you, you should consider using web
>services instead of remoting.
>
>Lluis.
>
>> 
>> Regards
>> Aleksandar Dezelin
>
>_______________________________________________
>Mono-devel-list mailing list
>Mono-devel-list at lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
>_______________________________________________
>Mono-devel-list mailing list
>Mono-devel-list at lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>



More information about the Mono-devel-list mailing list