do or die...

[Greg Stein <gs...@lyra.org>]

Somebody needs to start writing some code here... Otherwise, we'll probably
end up closing the project.

As I've mentioned before, I think somebody ought to just sit down and write
out what the header should be for the project. Once we have a set of APIs
"on paper", so to speak, then we can use it as a focal point for discussion.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: do or die...

[Aaron Bannert <aa...@clove.org>]

On Wed, Jun 05, 2002 at 05:06:44PM -0700, Justin Erenkrantz wrote:
> Ideally, lessons learned here in serf can drive any changes in
> httpd-2.1.  It seems that input side of things in httpd-2.0 has
> largely been ignored - something that absolutely can't be ignored
> for a client library like the mythical serf.

Definately. Especially for things like the proxy which have to deal
with both the server and client sides of HTTP.

I don't want to reinvent the wheel though, and there are many good
client-side HTTP libraries out there. I'd rather see us identify
problems (like the one in flood) that we want to solve. I think
having concrete problems will help drive development here.

> However, the biggest problem, IMHO, is the level of abstraction
> we want to have in serf.  I know Aaron and I have talked about it,
> but I'm not sure that anyone came to an agreement here.  I also
> know that Aaron has widly different views about the abstraction
> of things versus what is in httpd-2.0.  So, that may be worth
> discussing first (I'm not terribly sure if he's written up email on
> this)...  For starters, do we use the buckets and brigades from
> apr-util?

I wouldn't say "wildly" different, but indeed different. :) There was
some talk recently both here and on dev@httpd (not to mention IRC), but
I still feel it is too early for me to start talking design until I get
a better grasp of the kinds of problems I'd like to solve WRT filters
and abstract I/O.  Hopefully I'll have more solid ideas that we can talk
about as OSCON and even better at the hackathon.

-aaron

Re: do or die...

[Justin Erenkrantz <je...@apache.org>]

On Wed, Jun 05, 2002 at 04:31:50PM -0700, Aaron Bannert wrote:
> Do we need a killer-app (maybe flood is that app) to drive this?

I'd be willing to spend some time after we file the presentation on
flood for OSCon on the 10th (damn, that's soon).  Assuming of
course that httpd is in decent shape, which it isn't right now.
My priority is probably to get httpd in decent shape so that we
don't have to rethink things until 2.1 is open (whenever the heck
that might be).  So, when I'm satisfied httpd-2.0 won't blow up on
itself, I can spend time on serf.

Ideally, lessons learned here in serf can drive any changes in
httpd-2.1.  It seems that input side of things in httpd-2.0 has
largely been ignored - something that absolutely can't be ignored
for a client library like the mythical serf.

However, the biggest problem, IMHO, is the level of abstraction
we want to have in serf.  I know Aaron and I have talked about it,
but I'm not sure that anyone came to an agreement here.  I also
know that Aaron has widly different views about the abstraction
of things versus what is in httpd-2.0.  So, that may be worth
discussing first (I'm not terribly sure if he's written up email on
this)...  For starters, do we use the buckets and brigades from
apr-util?

> Where do we draw the line between kitchen sink and a "must have"?

I'd say whatever is necessary to support a flood and SVN is a
"must have."  -- justin

Re: do or die...

[Aaron Bannert <aa...@clove.org>]

On Wed, Jun 05, 2002 at 04:13:01PM -0700, Greg Stein wrote:
> As I've mentioned before, I think somebody ought to just sit down and write
> out what the header should be for the project. Once we have a set of APIs
> "on paper", so to speak, then we can use it as a focal point for discussion.

Maybe easier said than done. Perhaps we don't quite understand what kinds
of problems we'd like to solve here. I for one would like to solve some
problems in flood using apr-serf, the most interesting being abstract
I/O (we need to do client-side verification of returned data in a way
that is modular so that different verification pieces can be added and
removed at will). This is of course a huge goal, so it might make more
sense to start focusing on smaller goals and work our way up.

What client-side utilities are missing from APR that are necessary
here?

Do we need a killer-app (maybe flood is that app) to drive this?

Can/should we merge some code that is already out there, like apreq?

Where do we draw the line between kitchen sink and a "must have"?

-aaron