Re: OS agnostic substitute for Microsoft COM?
On May 20, 6:45 pm, Mathias Gaunard <loufo...@gmail.com> wrote:
On May 20, 5:34 pm, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
1. serialization marshaling of data elements
2. naming
3. numbering
4. addressing
5. a base "server" class
6. derived classes of class server
7. dispatching of server objects (so that they run with their own
thread when dispatched)
8. portable threading and synchronization model
9. RPC framework, where services codes map to member functions of
derived "server" classes
10. security (authenticity and privacy using combination of symmetric
cryptosystem, asymmetric cryptosystem, hashing)
11. mobility (you probably don't need this)
12. multicasing (you probably don't need this)
Isn't that just Boost.Channel, built on top of Boost.Asio,
Boost.Thread, Boost.Shmem and Boost.Serialization ?
Perhaps.
I just took a quick look at Boost.Asio and Boost.Channel. I had seen
Boost.Serialization before.
Without denigrating Yigong Liu's work, I guess the difference with our
framework is that we tried very hard to keep the complexity barrier
low. We also provide mechanism, not policy, so that almost all of the
primitives have the abstraction level of, say, map<>. We have done
this for 150+ primitives. Then we define slightly more complex
classes from these primitives, but still simple enough that one should
be able to guess how to use most them by looking at list of member
functions. Then we get out of the way.
So I guess, yes, end the end, all of these frameworks, including ours,
get data from Point A to Point B. Of course, as far as I know, ours
is the only one that allows the source or target nodes of an Internet
connection to be moving at 50 km/hr, while still maintaining the
stream (with security, multicasting, etc), but again this is just
research.
Finally, all of the primitives involved, from threading, timing,
network, etc...were designed by a single individual and coded by the
rest of us, so there is a consistent feel to the class hierarchy and
reduction in complexity space as all the components fit more or less
compactly. As stated before, I am not sure this was a good idea, as it
implies that basic data structures like map<> or set<> from STL cannot
be used.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]