<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=windows-1252">
<META content="MSHTML 6.00.2900.2180" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 12pt Arial">
<DIV>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.</DIV>
<DIV>&nbsp;</DIV>
<DIV>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.</DIV>
<DIV>&nbsp;</DIV>
<DIV>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.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Anyway, that's my 2 cents on the issue.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks</DIV>
<DIV>&nbsp;</DIV>
<DIV>Richard Norman</DIV>
<DIV><A href="mailto:Jazzynupe@sbcglobal.net">Jazzynupe@sbcglobal.net</A></DIV>
<DIV><A href="http://jazzynupe.net/blog/">http://jazzynupe.net/blog/</A></DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><BR>&gt;&gt;&gt; mono-devel-list-request@lists.ximian.com 9/29/2004 
3:32:47 AM &gt;&gt;&gt;<BR></DIV>
<DIV><BR>Message: 8<BR>Subject: Re: [Mono-devel-list] un-interoperatible classes 
.NET -&gt; Mono<BR>&nbsp;&nbsp;&nbsp; remoting<BR>From: Jonathan Pryor 
&lt;jonpryor@vt.edu&gt;<BR>To: Aleksandar Dezelin 
&lt;dezelin32@fastmail.fm&gt;<BR>Cc: Mono Development List 
&lt;mono-devel-list@lists.ximian.com&gt;<BR>Date: Wed, 29 Sep 2004 06:23:51 
-0400<BR><BR>On Tue, 2004-09-28 at 04:07, Aleksandar Dezelin wrote:<BR>&gt; does 
anybody knows what classes are un-interoperatible between Mono and<BR>&gt; .NET 
regarding remoting? I've found thar Hashtable is one of them but I<BR>&gt; don't 
understand why? Can somebody explain this topic little further?<BR><BR>It should 
be noted (because I haven't seen anyone else mention it) that<BR>remoting is 
ONLY guaranteed to work if you're using the same runtime<BR>version on both 
ends.&nbsp; This applies to *both* mono and .NET.<BR><BR>In particular, remoting 
between .NET 1.0 and .NET 1.1 WILL NOT ALWAYS<BR>WORK.&nbsp; If *anything* of 
the internal structure of a class changes,<BR>remoting fails.&nbsp; 
Consequently, .NET 2.0 and .NET 1.x are also not likely<BR>to work in all 
circumstances either.<BR><BR>Wanting Mono to interoperate with all versions of 
.NET is asking for a<BR>bit much, especially when Microsoft can't do the same 
thing.<BR><BR>Which leaves you with the suggested solution: take control 
of<BR>serialization yourself, so that *you* can ensure that all platforms 
are<BR>compatible.&nbsp; This can be done through Jason King's middle layers, 
or<BR>though web services, or through some other mechanism.<BR><BR>The key point 
is that you CANNOT rely on the default remoting<BR>functionality when you have 
different CLI implementations on either end<BR>of the remoting boundary.&nbsp; 
Remoting is very brittle.&nbsp; Which is probably<BR>why Microsoft is working on 
Indigo for the .NET 2.0 remoting solution,<BR>which will merge remoting, web 
services, and related functionality.<BR><BR>- Jon<BR></DIV></BODY></HTML>