On Monday 28 October 2002 09:51 pm, Greg Turner wrote:
Back to Ove:
The endpoint mapper is a service that's accessed through RPC, it shouldn't be a client-side feature in shared memory. In Windows, the local endpoint mapper is hosted by rpcss.exe. (In Wine, it could be implemented by launching a Wine-rpcss whenever we need an endpoint-mapping service to hold an endpoint registration, and make it stay alive for (only) as long as the endpoint registrations it holds are still alive.)
Smart! Now that you mention it, I remember reading in the DCE spec that this is, indeed, how it's supposed to be (not the rpcss part, but the idea that RPC itself is used to implement the endpoint mapping). It seems a little screwy to me (especially in light of the chicken-and-egg issue it creates) that DCE should dictate the means by which you achieve the result, as opposed to the result itself; but that's exactly what they do, IIRC.
I just remembered why DCE specifies the endpoint mapping mechanism with such particularity... it needs to work across hosts (duh).
I'm going to try to look into some of the issues we've been discussing some more after work today; perhaps, now that we have a marshalling prototype that works (at least so long as there's no mismatch in data representation), it wouldn't be too hard to just flesh out the remaining marshalling features needed by the endpoint mapper. This might be wishful thinking, but If DCE says we have to use RPC for this, they probably also provide the neccesary IDL or pseudo-IDL in the spec.
I guess I'm back to a "do it right the first time" mentality with this line of thought, but if I'm going to all the trouble to move the endpoint mapping features from the wineserver to a separate (winelib) executable, I'd might as well just code it to spec from the beginning. This would also allow us to begin interoperability testing sooner, which is a very good thing IMO.