I just signed up to this newsgroup, so apols for the late reply.
Actually I was also thinking of how to implement an object model on top of
SOAP and with emphasis on providing a general way of doing general
client-server "object" accessing without the COM/Corba bloat (and using
Mozilla). I particularly want to ensure:
1) C++ support (inc. from Javascript on Mozilla)
2) No cluttering/repetitive manual marshalling/demarshalling code on either
the server or client (not even using manual helpers which can convert basic
types to and from XML). Instead, do it once generically, then anyone can use
it.
3) Safe interfaces. In other words, the client must use the parameters/types
expected by a particular interface/method before it can even make the call,
ideally with invalid use being spotted at compile time, or at least
pre-transmission. This should allow for the fact that interfaces do change
over time.
So it occurred to me, why not provide a SOAP "wrapper" allowing XPCOM
objects on the server to be accessed by the client over SOAP in a manner
which fulfils the above, i.e.:
1) Write a SOAP server for the Mozilla platform (or use any existing one)
2) Make it parse SOAP requests against available (on the server) XPCOM
interfaces for which typelibs are physically present, doing the
demarshalling/remarshalling automatically from the typelib info.
3) Have something similar on the client (as a Mozilla-resident class), also
working from typelibs (or introspection - see below) and providing automatic
marshalling/demarshalling.
4) Make 2) support introspection (again, directly from typelibs) so the
client can do its stuff with dynamic discovery of interface details if
compiling against C++ headers isn't possible (eg. for script code)
This is mainly for adding server functionality in C++ (or whatever else can
use XPCOM, eg. Javascript/Python?) and being able to have client-side code
access it in a safe and mostly high level way (just like "real" RPC) . It
could be considered a lightweight, SOAP-based COM/Corba ("DXPCOM"?,
"XPDOM"?), "lightweight" because there's no infrastructural support for
remote object lifecycle management. It is, of course, the latter which
largely adds to the bloat/complexity of the current "real" distributed
object technologies.
What do you think - is this similar to what you had in mind?
Cheers,
Chris
