Re: More migration of code from httpd to apr-util

[Luke Kenneth Casson Leighton]

> > If the server spawns the programs, then you can also use regular pipes.
> 
> I have been thinking of creating apr/rpc/...   to handle stuff like this.
> However, right now, we have named pipes.  They need to be implemented on
> more platforms, and that may require changing the API a bit, but please
> let's stick with what we have already.
> 
> The only thing we can't do with named pipes today is communicate with
> different machines.  IMHO, calling any cross-machine communication medium
> a named pipe is just going to confuse any unix programmer.  Give it a
> different name.

hiya ryan,

i promised i'd get back to you after having had to leave quickly.

RPC.  okay.  building RPC directly into apr libs is something i can
strongly recommend you don't do: it could easily get out of hand,
make the code bulky, and most people would wonder what drugs you
were taking today [i.e. it goes against what i am beginning to understand
to be the APR ethos].

however, what i _can_ recommend is a slim wrapper - a *local* 
named-pipe (ux-dom-sock-based, tcp-loopback-based, NT-NamedPipe-based,
doesn't matter what the implementation is) that feeds to a
separate program that is responsible for locating and communicating
remote procedures.

a bit like the epmapper on dce/rpc but also a transport as well.

it will take a bit of work to design, however what you end up with
is a very small library that apps have to link with, they also
have to run this [entirely separate] program, and voila you have
RPC.

now, if you're concerned about this design, well... uh... how
do you think NT provides RPC? :) :) :)

worse than that, they put these mechanisms *in the kernel*!
[services running as System, and of course they _have_ to
be optimised and of _course_ that means running parts in the
kernel, agh!]

[i.e., if you're concerned, be concerned about using NT :) ]

all best,

lukes