From: Simon Kitching <simon@...>
Date: 2003-11-20T14:08:51+09:00
Subject: Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata	about attribute types)

On Thu, 2003-11-20 at 16:42, Austin Ziegler wrote:
> On Thu, 20 Nov 2003 08:53:21 +0900, Sean O'Dell wrote:
> > Why only in SOAP or RPC mechanisms? What makes them different from
> > someone who calls into a library?
> 
> SOAP, for example, is meant for use by a variety of different
> languages and rather expects type mechanisms, mostly because it was
> first designed for languages that require static typing. I can
> either build the SOAP description manually or have meta-information
> available.

Plus the fact that when you're passing data rather than object
references (which is the case with any remote invocation), you need to
do one of the following:
(a) 
expect exactly the same class at the other end,
(b) 
serialize the class (executable code) and send it along with the data,
(c)
serialize the object's data in such a way that *equivalent* types can be
instantiated at the other end.

Option (c) is the usual approach. However this implies that you need to
know the "type" of the data, so that an equivalent can be created at the
receiving end.

Even when doing Ruby->Ruby remote invocations, I presume that type
information is required. Any of the "distributed ruby" people here care
to comment?

I presume that even things like developing Gnome components via Bonobo
(which uses ORBIT) require strictly typed interfaces, whether the
component being interacted with is remote or in-process?


> I don't really want a "prescriptive" mechanism -- it makes the interface
> too brittle. If I wanted something like that, I think that I'd want 
> something like the rudimentary DbC stuff that Dave & Andy put together.

Does anyone have a URL to "the rudimentary DbC stuff"?

Cheers,

Simon