Hello --
I'm looking to use APR and APR-util to make my application much more portable. The basic design of my application is: a single, persistent, threaded daemon with which various small, lightweight programs (usually CGI scripts) must share data (two-way). All the daemon's programs are on the same machine, currently, but that could change. These two components together provide the server. There is also a client-side library, which is completely independent of the server.
APR/APR-util includes thread support, DSO support, LDAP support, XML support, DBM support, in short, almost all the things I need for my application (except Kerberos, but that's already a standard interface across platforms, at least with MIT Kerberos; let's ignore MS Kerberos and Heimdal).
The socket model seems to be the most elegant way of thinking about the connections between the daemon's client apps and the daemon: the shared information (the location of the socket) is constant across all applications, and the daemon can have multiple connections via that same socket at the same time. Shared memory requires a different key for each segment, so you have the problem of trying to get that conveyed to the server daemon. The applications are NOT children of the server daemon, so the proposed apr_spipe_t isn't useful (as far as I understand that proposed type). If there's another way of doing this sanely and elegantly without sockets, please let me know.
The data passed between the two components will include sensitive data, like passwords, but the responsibility of protecting that data will rest on the shoulders of the administrator, so the administrator could set up a private network between front-end webservers and the back-end daemon server, if he wanted to do complex things with load balancing. However, local sockets are the perfect, simple, lightest-weight solution, for those platforms that implement them, and that's currently the only way I support doing this connection. I'd rather not have to implement this two different ways for two different platforms, since that would require my application to be complex in a way I'd rather it not be. However, if APR had local sockets, I could have a configuration directive like <socket type="local" path="..."/> or <socket type="network" address="..."/>, and then set up the socket appropriately, with very little complexity, and then read from it and write to it in a sane and standard way.
I know this has come up on this list before, and nothing was really decided, at least on the list. The argument was made that it was a similar situation to IPv6 sockets on, eg, current versions of OS X, or Solaris 2.6, or, indeed, certain versions of Windows -- the APR must return APR_ENOTIMPL for certain socket types on some platforms, if you support IPv6. I would agree with this, and since AF_UNIX/AF_LOCAL is pretty widely supported in the UNIX world and has been for a long time, I'd be willing to bet that the percentage of platforms for which you'd return ENOTIMPL is much less for AF_UNIX than AF_INET6. And it's just so darn useful!
I hereby get down on my knees beg for support for this type of socket. If it is the lack of time to code it that is holding it up, I'll gladly take a stab at implementing it. I haven't played much with the internals of the code, only the headers with the intent of using the library, but I'm more than willing to learn if it means I can make my application even more able to wash its hands of platform-specific complexity.
In any case, thank you for making APR. I was really beginning to worry that I'd have to become a Windows programmer to get my application to work sanely under Windows. ;)
KH
-- Karsten Huneycutt A casual stroll through a lunatic [EMAIL PROTECTED] asylum shows that faith does not http://www.duke.edu/~kph prove anything --Nietzsche
