Re: the dreaded rpcss patch (rpc_J_PL0)

[Alexandre Julliard]

Greg Turner  writes:
> - configure; 
> configure.ac; 
> dlls/rpcrt4: .cvsignore, Makefile.in, rpc_binding.h, rpcrt4.spec,
>   rpcrt4_main.c, rpc_epmap.c (new);
> include: rpcdce.h, rpcdcep.h, rpcndr.h, winbase.h;
> include/wine: rpcss_shared.h (new);
> programs: Makefile.in;
> programs/rpcss (new dir): .cvsignore (new), Makefile.in (new),
>   README (new), atomicity.c (new), epmap_server.c (new), 
>   named_pipe_kludge_client.c (new), named_pipe_kludge_server.c (new),
>   rpcss.h (new), rpcss_main.c (new):
> Greg Turner ,
> Ove Kåven
> - a preliminary implementation of endpoint-mapping via a new
> on-demand server-ish process ("rpcss.exe.so")
> - more header fixups
> - (re)implement RpcEpRegisterA, RpcEpUnregister, and RpcEpResolveBinding
> using the new rpcss functionality
> - update the todo list in rpcrt4_main.c a bit

A few things:

- Please don't name files 'kludge_something'; this makes it impossible
  to implement things properly without renaming files.
- Don't share C files between rpcrt4 and rpcss, just copy the stuff
  you need (and at least atomicity.c doesn't seem necessary at all,
  you could just as well make mutex calls directly).
- Please get rid of the various #ifdefs.
- It would be better to put the README documentation directly in
  rpcss_main.c, people don't notice README files in subdirectories.

the dreaded rpcss patch (rpc_J_PL0)

[Greg Turner]

On Monday 18 November 2002 05:48 pm, Alexandre Julliard wrote:
> A few things:
> - Please don't name files 'kludge_something'; this makes it
>
> impossible to implement things properly without renaming files.

ok.  since it's a possibility to keep the named pipes kludge for local 
RPCs even once we do have a proper implementation, this is an 
especially sensible request.
> - Don't share C files between rpcrt4 and rpcss, just copy the stuff
> you need

hmm... for the named pipe client-side functionality this seems like it 
would create an awfully large amount of code duplication... can I 
export these from a dll somewhere?  or could I just put them in 
rpcss_shared.h?  the prospect of keeping two identical units in sync 
seems awkward.
> (and at least atomicity.c doesn't seem necessary at all,
> you could just as well make mutex calls directly).

I guess you are right, not sure why I did it that way...
> - Please get rid of the various #ifdefs.
> - It would be better to put the README documentation directly in
> rpcss_main.c, people don't notice README files in subdirectories.

10-4.  Let me know if you have any suggestions about the code 
duplication thing and I'll fix these things up and resubmit.

the dreaded rpcss patch (rpc_J_PL0)

[Greg Turner]

On Monday 18 November 2002 05:48 pm, Alexandre Julliard wrote:
> - Don't share C files between rpcrt4 and rpcss, just copy the stuff
> you need (and at least atomicity.c doesn't seem necessary at all,
> you could just as well make mutex calls directly).

Still hoping for some guidance on this.  I'm happy to get rid of 
atomicity.c as you suggest, but less happy about duplicating the (to be 
renamed) named_pipe_kludge_client.c unit.  The prospect of keeping two 
identical units in sync just rubs me the wrong way... it's so blatantly 
non-orthagonal --- it seems, to me, that there must be a better way.

Previously I suggested

o shove it in some dll where it doesn't really belong (kernel32?)

o shove those functions into rpcss_shared.h somehow

A couple of other possibilities have occured to me:

o create a tiny new internal-only dll, i.e.: "rpcsscli.dll" which
    (so far) just contains the named pipe client functionality, and
    is consumed by both rpcss.exe and rpcrt4.dll

o put it in a new .h file (probably a slight improvement on the idea
    of shoving it into rpcss_shared.h, since I wouldn't have to worry
    about the functions getting redefined).

Are any of these acceptable?  I know I'm being somewhat anal, but I'd 
really prefer not to duplicate that entire unit, even if it is a 
relatively small chunck of code in the grand scheme of things...

Thanks,

the dreaded rpcss patch (rpc_J_PL0)

[Alexandre Julliard]

Greg Turner  writes:
> Still hoping for some guidance on this.  I'm happy to get rid of 
> atomicity.c as you suggest, but less happy about duplicating the (to be 
> renamed) named_pipe_kludge_client.c unit.  The prospect of keeping two 
> identical units in sync just rubs me the wrong way... it's so blatantly 
> non-orthagonal --- it seems, to me, that there must be a better way.

Do you really need the client connection stuff in rpcss?  As far as I
can tell it doesn't really do much, I'd suggest getting rid of it
somehow, and having the client part only in rpcrt4 and the server part
only in rpcss.

the dreaded rpcss patch (rpc_J_PL0)

[Greg Turner]

On Tuesday 19 November 2002 08:36 pm, Alexandre Julliard wrote:
> Do you really need the client connection stuff in rpcss?  As far as I
> can tell it doesn't really do much, I'd suggest getting rid of it
> somehow, and having the client part only in rpcrt4 and the server
> part only in rpcss.

that's a possibility.  its inclusion probably has more to do with my WIP 
attempts to build the skeleton for RPCSS than any real functionality.  
I'll take a look at that approach.