I've got 2 major operational problems with serf at the moment (this is after
Jason fixing several issues. Thanks!). Neither is technically a serf
issue, but they none the less make serf un-usable.
serf over SSL trips a core dump due to a double free bug in libcrypto-0.9.8
/libssl-0.9.8. neon hits this as well, but serf hits it much more often. I
can't get through any of my big test cases without a fault.
serf doesn't play well with some http-1.1 implementations (specifically
code.google.com). neon does fine here. It raises the issue of how many bad
http-1.1 implementations there are and how to validate serf to be "good
enough" to be the default.
-Dan C
On 6/8/07, Justin Erenkrantz <justin@erenkrantz.com> wrote:
>
> On 6/8/07, Eric Gillespie <epg@pretzelnet.org> wrote:
> > No, we've tried at Google, as well. It's got a long way to go.
> > That's my point: as long as it sits there unused, it's not going
> > to get any better. As a matter of fact, it seems likely to me
> > that it's only going to get worse.
>
> I kinda doubt it's got a 'long way to go' - it passes all of the
> regression tests on trunk - or did the last time I checked. True,
> ra_serf may need some polishing or a feature here or there - but I
> don't think it's going to need *massive* amounts of work - just people
> who are willing to add the features they think are missing before it
> is acceptable to them. But, it shouldn't need a tremendous amount of
> effort as all of the hard stuff is already done...
>
> FWIW, on serf-dev, Lieven said that he was looking into SSPI and that
> it looked fairly straightforward to add. *shrug*
>
> Again, ra_serf 'works for me' - I use it without issues. I'd advocate
> flipping the default on trunk and any lingering bugs will get worked
> out really fast. =) For those who really want the features that only
> neon provides, it'll still be there ready to be used - I don't see the
> harm in trying it. -- justin
>
>
Received on Mon Jun 11 20:15:42 2007