> > 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
