On Sun, Jan 16, 2005 at 05:44:26PM -0500, Wez Furlong wrote:
I've been distant from DCE for a little while, so I don't have all the details at the tip of my brain.
Luke isn't quite correct, but is mostly correct :-)
burblburble never truer...
FreeDCE doesn't contain a working DCOM implementation.
ah - i wasn't aware of that.
The following areas need(ed) some work for that:
1/ NTLMSSP (which we now have in freedce, thanks to Luke)
and GSS-API thanks to luke howard [although it's not needed for DCOM]
2/ The rpcd/endpoint mapper needs awareness of ORPC and implement one or two ORPC specific services in order to maintain the lifetime of remotely activated components.
which jelmer of the samba team is aware of because he has _also_ started implementing DCOM.
3/ The IDL compiler and marshalling stubs need awareness of ORPC 4/ On top of that, the local COM library needs to be implemented
Filling out these areas is *massively less work* than re-implementing DCE-RPC; I made a fair start on (2) and (3) 4 years ago, but lack of interest from the world at large (and a need to pay my bills) caused it to be put on hold.
thank you for filling in the areas in which my knowledge was hazy about what was involved.
Please believe me when I say that there is a large amount of non-trivial code in there; I have huge respect for the people that wrote it and the amount of time that it took to get it there. Don't forget that this is production quality code that has been used by huge players for years.
ibm, dec, fujitsu, entegrity, arthur anderson, HP - about the only people who _haven't_ really used it are sun microsystems because they are known to always chase after money, taking people off projects and putting them on others - so nobody in their right mind would consider awarding them a $500m contract.
I pity anyone that would think of taking on the task of re-implementing it, not because it's nasty but because it's a *huge* effort.
While I can't commit development time right at this moment (I'm booked up with the PHP project in most of my "free" time), I am happy to help in any other way that I can; I researched the implementation of DCOM quite heavily back then, so I probably have a better idea than most about getting it done.
--Wez.
PS: I'd *love* to have someone sponsor my employer (omniti.com) to have me work on getting this implemented.
Luke Kenneth Casson Leighton wrote:
I already checked out FreeDCE and the newly released DCE-RPC several days ago. Neither provides a DCOM implementation, neither resembles what we need. We may be able to take some code or ideas from them with some work to massage it, but there's not much of use there.
dear mike,
you are correct about DCE 1.2.2 not containing DCOM: it is FreeDCE that does.
other than that - with all due respect, and if i understand you correctly: you are wrong [or looking in the wrong place]
e see this:
http://cvs.sourceforge.net/viewcvs.py/freedce/freedce/dcom/dcom.h?rev=1.1&am...
which has been available for just over four years, now.
are you _seriously_ intending to reimplement the DCE/RPC IDL compiler - because that's what's required!!!
DCOM is DCE/RPC underneath: DCOM even has the uuids and transports of DCE/RPC. DCOM is just a c++ wrapper on top of some underlying c APIs, and from what i can gather, you "up" the revision numbers of the interfaces, which DCE/RPC can even do for you.
perhaps i should put you in touch with wez furlong who did the original FreeDCE DCOM work.
you _cannot_ be serious about reinventing the 250,000 lines of c code required to properly support DCE/RPC which is a prerequisite for supporting DCOM.
i can understand the samba team doing that, but _another_ project doing it???
please tell me i am wrong in believing that you are giving serious consideration to a _third_ DCE/RPC runtime and development environment, to compete with samba 4's GPL'd implementation which is in development and with FreeDCE's complete reference implementation which is available under an OSF 1.0 BSD-like license.
l.