On Sun, Jan 16, 2005 at 05:51:54PM -0600, Rob Shearman wrote:
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]
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.
I hope you're joking.
lacking expertise due to lack of funding and sponsorship is a more accurate picture.
A DCOM implementation is more than a header file containing a few comments and a few declarations of Win32 functions that are randomly placed in there.
i appreciate this.
are you _seriously_ intending to reimplement the DCE/RPC IDL compiler - because that's what's required!!!
We already have our own IDL parser. The only step left is for it to generate appropriate type format strings in the same format as Microsoft use.
the dce idl compiler consists of 70,000 lines of highly complex code, 20,000 of which is the data handling code.
DCOM is DCE/RPC underneath: DCOM even has the uuids and transports of DCE/RPC.
We know.
fantastic.
DCOM is just a c++ wrapper on top of some underlying c APIs,
No, it is an object oriented wrapper for normal RPC interfaces where a state parameter representing the object is implicitly passed to the function.
It has nothing to do with the language.
my apologies for being too brief and simplistic in an area where there are people who have more expertise, time and funding than i have.
and from what i can gather, you "up" the revision numbers of the interfaces, which DCE/RPC can even do for you.
No. DCOM interfaces always have a version number of 0.0. To create extend an interface you must create a new interface. Microsoft typically appends a number to the interface name and makes the new one inherit from the old one. I suggest you take a few minutes to read the DCOM draft specification, which should clear up a few misconceptions.
it has been a long time since i actually programmed with COM objects: MSVC 4.3 to be precise, in about 1994.
once again i apologise for my memory on these issues being rusty in an area where you have more expertise than i.
my main concern in mentioning the capabilities of FreeDCE are in an effort to save you effort.
perhaps i should put you in touch with wez furlong who did the original FreeDCE DCOM work.
What DCOM work?
i will let wez answer this one, if he is amenable.
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 think you're over estimating by a factor of 2.5 there. Sure, it is a large undertaking, but one that we can do one step at a time. We don't have to implement *every* protocol to start with and we don't have to implement every Ndr data type.
if you used FreeDCE you would not need to implement any.
you do realise that you are duplicating a project that already exists (FreeDCE) which is a BSD implementation
... and you do also realise that you are also working, albeit from a different angle, on exactly the same thing that the samba 4 project is duplicating?
i find this alternately hilarious and frustrating and on balance am quite torn about actually telling you in case you get offended about being told that you are doing a "not invented here" syndrome or something.
please: i am genuinely curious and seek enlightenment on this issue:
_why_ are you duplicating the efforts of two separate free software projects?
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.
No other project has implemented an API that is compatible to Microsoft's yet.
the area that i understand in particular detail is the DCE/RPC side of things, and i can say from experience that the capability of the DCE/RPC side of FreeDCE is outstanding
the area which i am not entirely familiar with is the DCOM side, and you have the knowledge and expertise in that area.
surely, therefore, it would be reasonable to evaluate FreeDCE for use in order to get from "here" to "there" in a far quicker time?