On Monday, January 20, 2003, at 06:26 AM, Tyler Close wrote:

> On Monday 20 January 2003 02:14, Robert Withers wrote:
>> Regarding your implication that a signature has to define
>> what exceptions it can throw,
>
> There wasn't that implication. The example is about the
> introduction of new types. The old code threw one type of
> exception, that its peers understood. The programmer then created
> two new types. The peers don't have these two new object types.
> The example is about maintaining interoperation in this scenario.

your right.  what you said had nothing to do with the signature having 
to declare those exception that it can throw.  I was commenting off the 
top of my head.  In rereading what  you originally wrote, what gave me 
pause was your stance on the less dynamic view that the other side 
would have to be independently upgraded to support the new types.  
There is no reason we couldn't dynamically build a meta-representation 
of the type, as well as start attaching facets to that type so it could 
operate in a service environment.



On Sunday, January 19, 2003, at 07:38 PM, Tyler Close wrote:

> On Sunday 19 January 2003 19:55, Robert Withers wrote:
>> WOS looks very interesting and very similar with the features
>> CDR offers.
>
> What are the features that CDR offers? Could you go through the
> initial list of requirements that you proposed and give the
> answers for CDR? Before making any decisions, I think we need a
> chart of the requirements and how each possible solution meets
> them.

I'll give it a shot:

CDR back-of-the-envelope analysis:
> 1. it should be a binary representation for performance and scalability
> reasons

yep

> 2. it does not have to be human readable

that's the meaning of binary, no?

> 3. it should be easy to define new encodings

yep, constructed CDR types

> 4. it should be easy to register mappings for new types

IDL.  interfaces can be published.  a new incoming types can be looked 
up in an interface repository.  this has nothing to do with encoding, 
but rather implementation resolution of encoding.

> 5. it should be a standard, if possible

yep.

I don't believe that your doc-code is a standard, while IDL is.


>
> Is Chapter 5 of CORBA the best reference for CDR? Is there a
> formal grammar anywhere?

good question.   thanks, David!


>
>> The difficulty with any of them is that you need a way to
>> specify and disseminate novel types.    Can the client propagate
>> types to the server in some way?
>
> Given that you are communicating between distict programming
> environments, there is nothing to propagate. In order to share
> types with E, you'ld have to implement a Kernel-E interpreter. At
> that point, you're no longer Squeak-E, but just E.

it's going to be tough to exchange behavior, but types should be easy.  
In java you can use a custom ClassLoader to dynamically load new types. 
  You would just need a builder, to build the class file.

>
>> can the two peers negotiate the types?
>
> This is handled by the type upgrade support in WOS.  The idea is
> that each peer implements its own interpretation of a type. A peer
> can then send a new type, along with its compatibility graph. If
> the remote peer doesn't understand the new type, it falls back to
> an older compatible type.

This is a super idea.  It allows protocol negotiation at the 
Application layer.

>
> In essense, the peers have negotiated, on-the-fly, a commonly
> understood type.

that is really cool.

cheers,
rob