Name, life-cycle, directory structure, autoconf, temporary kludges for wine rpcss subtitute?

[Greg Turner]

Sorry, in advance, for this barrage of questions... but I'm getting 
anxious to proceed with this thing.

Naming:

This guy needs a name if I'm ever going to start coding it.  How about:
Wine Remote Procedure Call System Server aka wrpcss.exe.so?  A little 
misleading with the "ss" thing, but this name will look familiar to 
windows users, and is more accurate than my previous idea of 
wine-epmap, since it will eventually need to do more than just endpoint 
mapping.

I pretend this is the right name below, but if there's a better one, 
just substitute that in everywhere you see "wrpcss" in the following 
discussion.

Life Cycle:

Some scenarios will require wrpcss to run all the time as a 
daemon-type-thingy; most wont -- the majority of scenarios require 
dynamic on-demand invocation and auto-termination upon unmapping of all 
registered endpoints, as Ove suggested.

Are command line arguments an appropriate way to differentiate between 
these modes?  This ends up going back to the open question of how to 
implement services in wine; but, of course, I don't want to wait for 
this to be resolved before proceeding.  Whatever solution wine 
implements for services, adapting wrpcss to it won't be insurmountable 
(assuming it's a good solution).

Also: if run as a service, how do I get "detached" without using 
"fork()"?  Is there some existing example of this I ought to emulate?

Directory Structure:

dlls/rpcrt4/wrpcss/ ?
programs/wrpcss/ ?

Autoconf:

I can try to implment the necessary infrastructure myself, but if 
history is any guide, I will screw it up.  If anyone is feeling 
generous with their time, they could give me a skeleton to fill in.

Temporary Kludges:

DCE does, indeed, provide the necessary idl to implement the endpoint 
mapper.  Unfortunately, although the IDL is reasonably simple, there 
are just too many types in there to "do it right" from the beginning.

Meanwhile, I am getting sick of dragging along the unmerged server parts 
(it isn't that hard, but I'm lazy).

So, as discussed earlier, I propose the named-pipes hack until a full 
implementation is possible.  I would, of course, take some care to keep 
the kludge-based parts separate from meaningful, potentially permanent 
parts of the code... howsabout I just listen at \\.\pipe\wrpcss for the 
time being?

thanks for your input,

-- 
gmt

"The purpose of government is to rein in the rights of the people"
 --President Bill Clinton, MTV interview, 1993