On Tue, Oct 24, 2000 at 10:26:42AM -0500, Ben Collins-Sussman wrote:
> Greg Stein <gstein@lyra.org> writes:
> >
> > ... whoops. I just forgot. I don't think Neon is running on Windows. Hrm.
> > That could pose some problems.
>
> Is Neon using all sorts of Unix-specific system calls? I mean,
> Berkeley TCP/IP sockets are certainly portable to Win32, but what else
> is Neon using? Just curious here.
Neon only uses memory and socket calls. He probably wouldn't switch to
pools, but we may find some advantage there to do so (at least as an
option). However, using APR sockets would be a big advantage. While the
Berkeley APIs are more or less present on Windows, they really suck. Using
Native Windows socket APIs is much better. Therefore, using APR would be a
big bonus.
[ not to mention that Neon could also avoid some platform-specific socket
code and handling; APR may have some platform-specific optimizations that
aren't readily available to Neon without extra work ]
I spoke with Joe at length on this at ApacheCon. He is amenable to using
APR, but was concerned about the extra dependency and APR's library size.
For the dependency, it would be quite possible to have APR as an option,
with a fallback to Neon's current socket code (and since we have it in SVN,
we would simply configure Neon to use it). Regarding APR's size, that
shouldn't be a big deal. I just did a "strip" on libapr.a and was left with
an 82k .a file. I'm not sure of the internal ties between the modules, but
presumably Neon would use only a portion of that. [altho SVN would use the
rest]
So... there are certainly some wins for Neon to use APR. I believe the plan
will probably be that I'll need to do the APR-ization of Neon and submit the
work to Joe. Given that he is so-so on the idea in general, I can't really
expect him to do the work :-)
I'd guess that will happen in a couple months or whatever, after the bulk of
SVN has been completed.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:13 2006