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 features.
Why?
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 (boost-users). Snippet: "...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. Cheers, Slawomir