On Monday 20 January 2003 15:44, Robert Withers wrote:
> 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.

Facets are behaviour. How are you going to attach behaviour to an
unknown type without defining a universal runtime? Are you
planning to implement a Kernel-E interpreter?

Defining a universal runtime is a very different problem than
communicating between disparate runtimes. Which problem are we
solving?

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

Any stats?

>> 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.

How do you create a collision-free namespace for new types?

>> 5. it should be a standard, if possible
>
> yep.
>
> I don't believe that your doc-code is a standard, while IDL is.

No, but doc-code is just an alternate representation of the XML.
XML is a standard. There are standards for specifying the
structure of an XML document. XML also seems to be a more popular
standard than CORBA. If you're looking to jump on a bandwagon, XML
seems like the better horse to bet on.

Tyler
_______________________________________________
e-lang mailing list
e-lang at mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang