[Mono-devel-list] Re: Mono-devel-list digest, Vol 1 #1109 - 10 msgs

[Richard Norman]

Just a quick comment on this from me (I try to follow Don Box's exploits
in this world closely). I agree 100%. Remoting should be limited to
interappdomain/process communication. The recommenced path (according to
Microsoft) is to use ASMX primarily, or if higher performance is needed
use DCOM I believe. Remoting was reserved for communication between
processes where types can be "guaranteed" to be the same.
 
Also with Indigo they are going toward the "WSE" style of
interoperability. So instead of using a "remoting" style of interop,
they are using the ASMX style of connected systems where the contracts
are shared but not the types. I would recommend in Mono an investment be
made in the WSE classes as they would be a precursor to Indigo classes
in Mono. I know it will take some effort creating the channels and ports
and so on, but I think it would be a step in the right direction.
 
According to some of the quotes I've read, remoting is in a similar
state as COM.. It is not dead, but it is pretty much done. Most
development will be in the WSE style of coding and connecting.
 
Anyway, that's my 2 cents on the issue.
 
Thanks
 
Richard Norman
Jazzynupe at sbcglobal.net
http://jazzynupe.net/blog/
 


>>> mono-devel-list-request at lists.ximian.com 9/29/2004 3:32:47 AM >>>


Message: 8
Subject: Re: [Mono-devel-list] un-interoperatible classes .NET -> Mono
    remoting
From: Jonathan Pryor <jonpryor at vt.edu>
To: Aleksandar Dezelin <dezelin32 at fastmail.fm>
Cc: Mono Development List <mono-devel-list at lists.ximian.com>
Date: Wed, 29 Sep 2004 06:23:51 -0400

On Tue, 2004-09-28 at 04:07, Aleksandar Dezelin wrote:
> does anybody knows what classes are un-interoperatible between Mono
and
> .NET regarding remoting? I've found thar Hashtable is one of them but
I
> don't understand why? Can somebody explain this topic little
further?

It should be noted (because I haven't seen anyone else mention it)
that
remoting is ONLY guaranteed to work if you're using the same runtime
version on both ends.  This applies to *both* mono and .NET.

In particular, remoting between .NET 1.0 and .NET 1.1 WILL NOT ALWAYS
WORK.  If *anything* of the internal structure of a class changes,
remoting fails.  Consequently, .NET 2.0 and .NET 1.x are also not
likely
to work in all circumstances either.

Wanting Mono to interoperate with all versions of .NET is asking for a
bit much, especially when Microsoft can't do the same thing.

Which leaves you with the suggested solution: take control of
serialization yourself, so that *you* can ensure that all platforms
are
compatible.  This can be done through Jason King's middle layers, or
though web services, or through some other mechanism.

The key point is that you CANNOT rely on the default remoting
functionality when you have different CLI implementations on either
end
of the remoting boundary.  Remoting is very brittle.  Which is
probably
why Microsoft is working on Indigo for the .NET 2.0 remoting solution,
which will merge remoting, web services, and related functionality.

- Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040929/4e03a88b/attachment.html