[e-lang] [RFP] cross-language object serialization (E <--->
vze2729k at verizon.net
Mon Jan 20 22:49:09 UTC 2003
On Monday, January 20, 2003 5:05 PM, Mark S. Miller wrote:
> At 12:00 PM 1/20/2003 Monday, Robert Withers wrote:
>>> Regarding the operation signatures, we could adopt the
>>> CORBA Typecode specification as well and require that all
>>> objects provide a remote Miranda method for acquiring a type
>>> specification of the complete interface that is exported by
>>> the object. I understand that this is the approach taken by
>>> the CapIDL team in order to eliminate the requirement for an
>>> Interface Repository - and the attendant trust issues that
>>> it would bring.
>> I really like what you have said here. Do you have a link
>> to CapIDL?
> http://www.capidl.org/ , but the info there is currently stale.
> CapIDL is under active development by the EROS group, and I
> remember accessing the sources from either the OpenCM or CVS
> repositories through a web interface. However, I can no longer
> find it. If someone has a current URL, I'll link the capidl.org
> page to it.
Just happened to discover it last night :-)
>> Getting rid of the IR and embedding it in the CapTP protocol
>> sounds very agile.
> Yes. An interface repository is a fatally broken idea, because
> of the trust issues that David mentions. This issue *must* be
> solved in a fully decentralized manner.
I've been mulling over a response to a part of Robert's message
that Mark didn't quote, where Robert said:
"This sounds just right. Can they be versioned so that an
incoming type can make an assertion about which version of a
type he should be interpreted as?"
As I thought about this problem, I concluded that a possible
approach, which could be incorporated into the CapTP protocol,
would be to have the request protocol message include the
expected type of the called object, represented as a crypto-
hash of a canonical type specification format (such as a CDR
encapsulation of the type - expressed as a graph of CORBA
TypeCodes, as would be seen in a CORBA Interface Repository).
If the hash doesn't match a hash of the type actually exported
by the called object, the called object's Vat would return an
intermediate response exception that contains the full type
specification that *is* exported. The calling Vat can then
adjust its behavior based on configured policy (e.g., check
to see if the new graph has a signature compatible with the
call being made or return an EBadType exception to the caller).
I'm pretty sure Jonathan and Mark have thought about this, so
I look forward to hearing their perspective.
e-lang mailing list
e-lang at mail.eros-os.org
More information about the Squeak-dev