Slawomir Lisznianski 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. I guess that other standards allow this as well (which is actually good if you take into account applications like generic bridges or languages with extensive support for reflection).
and use of a subset of native-language features.
Why?
Here, the goal is to support virtually any C++ type, including user types, (say, compatible with Boost Serialization)
OK.
Apart from that, how do you plan to encode *names* of messages, if in the code they exist only as compile-time names of types? The server has to somehow map incoming message to one of the registered operations. How?
Each operation is part of an interface type, and has a unique id (enum) within that interface.
1. How is this id supposed to be allocated? 2. Who has the responsibility to assign unique ids to operations? The above issues are not clear from the code examples you have shown. I guess that it is the *order* of types that appear as the parameters to the interface template, right? What about "objects" and their lifetime? It would be very limiting to have only one "set" of operations in the server. The library has to support many "objects" (even having the same interface) that come and go during the work of the server. How to identify and address those "objects"? (I use quotation marks above to stress that "objects" in a distributed system are of logical rather than C++ nature. In the most straightforward implementation, each such "object" is implemented by a separate C++ object on the server side - and their lifetimes match - but that need not be the case in general.) How about clients addressing the servers? -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/