I am interested to move forward, but before I can do that I need to do some rummaging around inside XPCOM to make sure I understand well enough how it works not to muck anything up as I begin work on D-XPCOM. I also want to talk this over with some of the other developers on my team and be sure that we're all on board.
As far as us doing the work... I understand totally and I'm all for that. I've got a reasonably good understanding of the guts of M$ COM, and I'd be using that as a design template. In addition, I agree that we should consider security as a key design consideration.
I'm still coming up the curve on XPCOM and its implmentation. I've only been playing with it for a few weeks and that only in a prototyping mode.
When I get my act together (I'm guessing in about two or three weeks), I'll send you and e-mail with some ideas on how I think we can begin to move forward.
Rob [EMAIL PROTECTED]
Doug Turner wrote:
Robert S. Kerr wrote:
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]
