I agree with Leif. We don't want to be in the business of creating out
own version of libraries with special patches and tweaks. The process
would be the same for any other library we depend on (glibc, openssl, etc.)
We should only depend on libraries that are stable and reliable. I am
still apprehensive about including libev as a dependency, but it has
little to do with the license.
- Does it handle edge triggering? (I didn't see anything about level vs
edge in the man page)
- What other projects use it?
- Why does everyone seem to roll there own even handlers?
- How active is the development?
We can talk more about it when we are in the office tomorrow and/or
apachecon...
-Bryan
On 11/01/2009 03:28 PM, Leif Hedstrom wrote:
On 11/01/2009 03:34 PM, Andrew Hsu wrote:
If libev is a well-worn library that we can depend on like libc, then
the risk is small to just link it up. We can depend on it to kickass
for free.
I don't know how "well-worn" it is yet, but then this is an argument
to leave the "native" epoll() config in there for a while :).
However, if there is a bug in the event loop that we need an
emergency fix for then we have to consider the license if we want to
ship portions of modified libev code. If the license is
incompatible, we need to pressure libev to push the fix.
I think that's incredibly unlikely to happen, I'd imagine we'd
pressure libev for a fix, or, provide a patch to it and let people
build their own version of the library. And, any distro can do the
same, i.e. the libev code with fixes doesn't have to be part of Apache
Traffic Server source distribution. Many distros build packages with
their own patch sets anyways, so it's definitely not an uncommon thing
to do.
And in any case, if this is a serious consideration, we're already
screwed on so many levels, by relying on several libraries that are
not ALv2 compatible. I'd be very reluctant to include common library
code in our TS source tree to fix a bug in such library, even if the
licenses are compatible. Being part of the Open Source community ought
to give us more leverage too to get such bugs fixed in the libraries
in a timely manner.
Again, this could all be moot if libev's LICENSE is compatible with
ALv2 (which looks like it is). But the same consideration needs to
be taken for other event libraries with different licenses.
Yeah, if it's a moot point, lets leave it at that. I think going down
this hole, and try to cover for every possible library and
dependencies on those libraries would be painful, to say the least.
Lets provide patches to those libraries if/when it happens, and binary
packages can provide such fixes as necessary (without tainting the
Apache TS code base).
I'd be curious to hear if any of our mentors or HTTPD developers have
any thoughts on this? Is this generally something you worry about,
depending on non-ALv2 compatible libraries (like, glibc)?
Cheers,
-- Leif
