From: Maciej Sobczak (prog_at_[hidden])
Date: 2005-09-18 15:45:46
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/