--On November 25, 2005 12:20:27 AM -0800 Greg Stein <gstein@lyra.org> wrote:
> Neon is designed with a synchronous model in mind. It would need to
> change rather dramatically. Possible to do, of course. It's just a
> simple matter of programming :-)
>
> That said, there were a number of other things that we wanted to
> explore in designing an HTTP client library when we started serf:
> filtering, minimal-copy, multiplexing connections, etc. Serf has a
> very different API model (which is not very friendly right now, which
> is one of the problems that needs to be fixed).
Friendly based on who the developer is. =)
If you're familiar with how httpd's filters/brigades work, it isn't that large
of a conceptual leap to use Serf. Serf does a number of things differently
than httpd on purpose because, well, httpd did it wrong.
The learning curve for someone who isn't already familiar with how httpd 2.x
does filtering/brigades would be more substantial though.
Funny aside: I was talking with a colleague in my research group who has been
writing a high-performance Python HTTP client and he 'stumbled' upon the
conceptual design of serf without knowing anything about httpd or the work
we've done with Serf. Our conversation went like:
Colleague: "Um, what exactly are you doing?"
Me: "Writing a high-performance REST [HTTP] client library in C."
Colleague: "Hmm. I'm doing that in Python for my XYZ app."
...silence...
Me: "We should talk."
...silence...
Colleague: "Yah."
Me: "We're in the same group, you know."
Colleague: *sigh*
He named everything differently from what Serf does, but it's clear he wasn't
that far off conceptually and he did it without any knowledge about what I've
been doing with Serf. So, he didn't think that the Serf design was
non-intuitive at all. ;-) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Nov 27 09:19:44 2005