Doug,
First, thanks for responding.
If I might ask, how far did you get with the prototype?
For some background - my company is currently looking at architectures for a workgroup server we're building. I'm the architect for the system. We've been considering the usual suspects (DCOM, CORBA, J2EE, etc.) for inter-component communications, but we find the cross platform aspects of XPCOM very appealing. (We also like J2EE, but we're a little concerned about performance there and we have a large body of code that is C++ already, so doing all the wrappers would be unfun.) Based on our understanding of XPCOM, it compares very favorably with COM (with the exception of a sizeable market for third party components, but that isn't really an issue for us.) The only real drawback for us with XPCOM is that we know that eventually we'll want to scale the architecture and we would be doing that across component boundaries.
If I got a sense that the XPCOM community was friendly to these kinds of enhancements (and it sounds like at least you are, and I'm presuming given your activity in news groups, that you speak with some significance) and would be amenable to source improvements to make it possible, then I might be able to convince my team that XPCOM is a good way to go for us.
Thoughts, Rob
I was able to create objects in a remote process on the same machine [1]. I could then use a proxy object to control the behavior of the remote object. I got as far as being able to pass primitive data type to the remote process. For example, I could create a simple object on the remote machine change various values. I didn’t find that the implementation would be very hard – there are many similar examples of what needed to be completed. However, I don’t want to fool you, it is a lot of work to get something completely working. I can give you a hand to get started, and, if you require, maintain the work once it is done. However, I am looking for someone that can do the actual developement/coding.
[1] The link between the two processes was a socket limited to the local host. I believe Darin (the person that implemented the lower level RPC services migrated this code to use higher-level system support (on windows WM_COPY message). I don’t think it would be that hard to toggle this back to a (tcp) socket so that the remote process could exist on a remote machine (Note no one has considered security implications of moving to a TCP socket since the RPC service that was written was meant to be for the local host only).
If you like, I can give you a call if this sounds at all interesting so that we can work one the preliminary details in a quicker fashion.
Doug Turner [EMAIL PROTECTED]
