httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter J. Cranstone" <cranst...@remotecommunications.com>
Subject RE: [PATCH] bucket problems.
Date Wed, 17 Jan 2001 22:16:46 GMT
Guys,

Feel free to flame me or plain ignore me but I have a suggestion. Why not
leave filtering out of the equation until the beta is stable. Filtering is
going to cause issues with 1.x modules and will take time to explain to your
existing base.

What I think you need IMHO is to get 2.0 stable with just one or two
features. You have enough on the table to do that. Then introduce filtering
at a later stage. Adding the whole thing now along with all the other
features is going to result in 1.x users avoiding the upgrade.

Backwards compatibility to older modules is KEY until you have the new
filtering system stable and OUT performing anything else. Then users will go
through the pain of adapting their modules for the newer more stable, faster
Apache 2.0

This is just a thought. Ignoring me will cost less effort than flaming me
but you know where I am :)

Regards,


Peter
RCI

-----Original Message-----
From: trawick@bellsouth.net [mailto:trawick@bellsouth.net]On Behalf Of
Jeff Trawick
Sent: Wednesday, January 17, 2001 2:51 PM
To: new-httpd@apache.org
Subject: Re: [PATCH] bucket problems.


rbb@covalent.net writes:

> > I think the very idea of an API which adds to a brigade is
> > problematic.  We want an API which handles output, sending it down the
> > filter chain when necessary (i.e., when our x-kilobyte coalesce buffer
> > is full).  With your API, some weirdo will create a filesystem with
> > infinite entries in a directory, and rather than having mod_autoindex's
> > processing of this directory limited by network I/O to the client,
> > mod_autoindex will loop until all storage is exhausted.
>
> You are taking a part of the patch that was a quick hack and extrapolating
> that it is the only way to do this.  I added the pass_brigade where I did
> because I wanted a working example.  A real example will actually have to
> make this call whenever it makes sense.

Do you mean that you would expect a module using this API to regularly
decide whether or not to call ap_pass_brigade()?  It would be really
nice to avoid that.  But avoiding it breaks your desire to avoid
having an API which knows about both filters and buckets.

> > I really think we want some changes with the coalesce property but
> > also the flush-to-the-network-as-we-go property, rather than
> > continually building up the brigade until the module sees fit to call
> > ap_pass_brigade().
>
> If you can design/implement this, please feel free.  As I see it, we have
> multiple people with different priorities.  This is what I have currently
> heard as priorities, please add any if I miss some.

As I recall, Victor already started down this road but was shot down.

> Don't change the ap_r* API at all
> Good performance for ap_r* functions
> Ability to use both ap_bucket_create and ap_r* functions in the same
> 	function
> Ability to use network congestion to stop sending data
> Don't allow the server to even try to use up all the memory
>
> You can't have all five of these.  Pick a few and design for them.

As long as the app calls a flush routine (ap_rflush()), all five of
these were met by Victor's patch if I recall correctly.

> > But to do that the API needs to know about filters too (enough to call
> > ap_pass_brigade()), so there is another parameter to
> > ap_brigade_something().
>
> No, that is tying the buckets to the filters, which ties buckets to Apache
> basically, which is not correct IMHO.

The app has to do extra work if this type of API doesn't handle
buckets and filters.

> It doesn't matter.  The biggest problem with Victor's patch is that it
> puts the buffer in the request_rec, which means that we aren't helping
> anybody other than Apache itself.

As I mentioned before, macros could avoid having the core code
know about the request_rec.

  #define ap_rputs(s,r) \
  ap_brigade_puts(r->field1, r->field2, x, y)

  (or some such)

But the key issue is whether some API knows buckets and filters.  To
meet what I thought was the goal ("Allow apps which use the ap_r* API
to perform reasonably"), I think we need such an API.

Thanks,
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...


Mime
View raw message