From: Slawomir Lisznianski (slisznianski_at_[hidden])
Date: 2005-09-18 19:28:58
Maciej Sobczak wrote:
>>Having cross-language support requires
>>external interfacing language
> Why? For example, in CORBA the use of IDL is optional and all
> communicating parties can rely on dynamic interface operations.
Well, at the cost of type safety. DII is also considerably slower and
relies on Interface Repository.
> ... or languages with
> extensive support for reflection).
C++ doesn't fit in this category, does it? ;-)
>>and use of a subset of native-language
Because you need to narrow down to what's common between languages for
which binding is to be provided. As an example, cannot use `unsigned'
type qualifiers or enums as they may not exist (Java comes to mind --
although they got enums in 1.5).
> 1. How is this id supposed to be allocated?
> 2. Who has the responsibility to assign unique ids to operations?
Template magic. Users don't know about "ids" -- they're inner workings.
> The above issues are not clear from the code examples you have shown.
Code examples were high-level (read, naive) and aimed to show user
interactions. Once I have you all wormed up I'll demonstrate code ;-)
> guess that it is the *order* of types that appear as the parameters to
> the interface template, right?
bingo, order is of quite significance!
> What about "objects" and their lifetime?
Good question. I have it partially answered in a parallel thread
"...CORBA-like object semantics with support for "transient" instances.
For example, when you construct a client-proxy, out of a portable
stringified reference, currently URI, you are pointing at a concrete
stub/servant instance. If that stub/servant was brought down, your
reference is no longer valid and "transient" exception is thrown on any
operations against it. In other words, say TCP address and port are not
pointing at a servant yet. It takes "instance id", think of it as `this'
pointer in C++, to reach a particular servant. Why this is considered
important? Because it allows for stateful remote objects. You can
construct N-number of instances of the same class of servant, and each
one will have a distinguishing reference that the client can call."
> It would be very limiting to
> have only one "set" of operations in the server.
Couldn't agree more.
> How about clients addressing the servers?
Once servant is up, it can be queried for a "reference to self". This
reference can be stringified (say, as URI). Client-side proxies use
references to refer to particular servant instances.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk