Topics Man wrote:
> Rick + all,
>
> I think I might start looking at making XPCOM work across processes as a first
> step in looking at all of this (without type library/scripting, to start off
> with). Do you think that is realistic?
Take a look at the code that handles proxy-ing calls to component methods across
threads. That mechanism allows two options: an asynchronous fire-and-forget method
call and a synchronous wait-for-results method call. You might end up doing
something very similar.
> Of course that means I have to write an in-process proxy, which will do the
> communication between processes. Which leads to an immediate question: what is
> the preferred way to do efficient cross-platform IPC within the Mozilla design
> (I'd do this in my sleep in native Win32 programming, but picking up existing
> Mozilla code/libraries and staying cross-platform is the name of the game
> here).
I don't think there is one so you are free to choose. Something TCP socket
based would be nice. You will probably want to use the threading proxy
mechanism mentioned earlier to prevent network IO from blocking the main
UI thread.
The real work is going to be on the server or "ORB" side which sits
and listens for component requests. You are very quickly encroaching
on CORBA/DCOM+ territory.
> Cheers,
> Chris.
Here are my thoughts on how to handle remote objects in a somewhat
generic fashion:
First, pick an IPC protocol like XML-RPC, XPC, HTTP, or whatever and
make that the de-facto XPCOM standard remote component protocol.
Second, extend the xpidl compiler to support "remoteable" as well
as "scriptable". In the case of a remoteable component, xpidl can
produce a complete compilable C++ proxy stub implementation of the
component's interfaces that translates each method call and attribute
accessor into a remote network request.
The nice thing about this approach is that as long as the interfaces
for a component are frozen the proxy stub never needs to be re-
generated and compiled. The downside is that you have to figure out
a way to distribute the proxy version of your component.
The alternative is to pursue what you were discussing earlier of
doing the marshalling on the fly at runtime.
The next evolutionary step is to create an ORB-like mechanism at the
server that publishes a directory (could even be done using *LDAP*) of
what components and services are available. THEN you get into
trust and security issues.
Regards,
Rick
