2.2 Roadmap?

[Paul Querna <ch...@force-elite.com>]

I believe it is time to look seriously at what would compose a 2.2
Stable Branch. There have been various threads in the past saying a 2.2
stable branch is not far off, and with the impending of release of APR-
1.0, we should turn our attention to HTTPd. 

While searching for something else, I found this interesting quote from
2002: http://www.mail-archive.com/dev@httpd.apache.org/msg06365.html

On Tue, 2002-02-26 at 11:26, Dale Ghent wrote:
...snip...
> There's no roadmap; There's no release date of any sort for the tree,
> be it alpha, beta, delta, zulu, red, yellow, or final. No code
> regression testing. 
>
> I kind of get the feeling that someone will wake up one morning and say
> "Hey, let's release 2.0!" and I fear that. Then the scramble To Get Stuff
> In ensues.

While I don't think the situation is that bad yet, there is a serious
lack of direction for the 2.1 branch.  The Roadmap is completely
outdated; it was last updated 19 months ago.

The 2.0 branch was made over 18 months ago, it is time to make another
stable branch. I believe many people want the AAA changes, and it brings
even more features to encourage people to upgrade from 1.3.

To better facilitate this, I would like to rewrite the ROADMAP with
specific goals for what will make up a 2.2 Stable Branch.  Lets make a
list of things that *must* be in 2.2, so we know when we reach our
goals.  Otherwise as Dale wrote in 2002, one morning someone will wake
up and say "Hey, let's release 2.2!".

This is only a list from my initial thoughts, please comment and make
suggestions. I will take the resulting thread and rewrite the ROADMAP
file.

*** Outstanding Issues ***

- Show Stoppers in STATUS:

   - Handling of non-trailing / config by non-default handler is broken 
http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105451701628081&w=2

   - the edge connection filter cannot be removed     http://marc.
theaimsgroup.com/?l=apache-httpd-dev&m=105366252619530&w=2

- LDAP Authentication 
   - Needs to use the AuthN/Z framework
   - Caching Code needs Stabilization or Removal(see AAA Cache)

- mod_cache
   - STATUS says it still violates RFCs. Whats going on? Is anyone
fixing it?
  
- All Experimental Modules: Improve it or loose it.

- Make Worker the Default MPM on for threaded Unix boxes?
    - Vote in STATUS says this should already be done.

- Document any API Changes for Module Authors.
   - We want to make this an 'easy' upgrade.
   - Most of the work IMHO is APR 0.9 -> 1.0

- Make _private.h files for all functions that are not part of the
public API.


*** Borderline Issues ***

- mod_zeroconf
   - Offered for donation. Status?

- Event Driven MPM
   - Greg Ames has a patch to add this. Needs stabilization, testing,
and performance improvements. I would like to see it in 2.2, but I don't
know how much time Greg has.

- AAA Cache Framework
   - Caching Method for all AuthN/Z backends would be nice
   - Possible todo this *without* API Changes.(Could be done once 2.2 is
stable)


*** Issues for 2.3.0-dev ***

- Replace the Perchild MPM with a different/working model.

- Allow Arbitrary File Backends.

This is only my initial list, please comment and add more.

-Paul Querna

Re: 2.2 Roadmap?

[Edward Rudd <ed...@omegaware.com>]

On Sun, 27 Jun 2004 14:56:37 -0700, Paul Querna wrote:

> I believe it is time to look seriously at what would compose a 2.2
> Stable Branch. There have been various threads in the past saying a 2.2
> stable branch is not far off, and with the impending of release of APR-
> 1.0, we should turn our attention to HTTPd. 
> 
I'm all for this. There are many new features in the 2.1 tree that I
definitely want to play with on a *stable* release.
> 
> - LDAP Authentication
>    - Needs to use the AuthN/Z framework
>    - Caching Code needs Stabilization or Removal(see AAA Cache)
> 
This is definitely something that needs to be updated. and will try to
give a full attempt in the next few weeks to find time to rewrite this
module for the authn/z framework.

> - Document any API Changes for Module Authors.
>    - We want to make this an 'easy' upgrade. - Most of the work IMHO is
>    APR 0.9 -> 1.0
> 

Documentation, what a novel idea. This is one of the major deficiencies of
the current 2.0 release, little in developer documentation and examples.

> - Make _private.h files for all functions that are not part of the
> public API.
> 
I like this one, This would make things clearer as to what should and
should not be used in a module (I reference my own blunder of accessing
ssl_lookup_vars directly instead of using the OPTIONAL_FUNCTION in my
mod_log_sql module as an example)


> - AAA Cache Framework
>    - Caching Method for all AuthN/Z backends would be nice - Possible
>    todo this *without* API Changes.(Could be done once 2.2 is
> stable)
> 
I feel this is a very important module to get working and stabilized.
Especially for use with LDAP authentication.
> 

Edward Rudd
http://www.outoforder.cc/

Re: 2.2 Roadmap?

[Brian Pane <br...@apache.org>]

Nick Kew wrote:

>On Sun, 27 Jun 2004, Paul Querna wrote:
>
>  
>
>>The 2.0 branch was made over 18 months ago, it is time to make another
>>stable branch. I believe many people want the AAA changes, and it brings
>>even more features to encourage people to upgrade from 1.3.
>>    
>>
>
>There's another consideration that could be relevant here: people who
>never touch an N.0 software release.  Bump it to 2.3? :-)
>  
>

With the release of 2.0, we moved to a model of "even
numbers are production releases, odd numbers are development
releases."  So 2.2.1 will be the right choice for people who
don't want to run N.0 releases.  :-)

>>This is only a list from my initial thoughts, please comment and make
>>suggestions. I will take the resulting thread and rewrite the ROADMAP
>>file.
>>    
>>
>
>Smart filtering.  We need much better dynamic configuration of the
>filter chain, with processing depending on the headers.  Think an
>AddOutputFilterByType that isn't a hackish afterthought, and extend
>that to work with more than just Content-Type.  It also fixes the
>awkwardness currently involved in ordering a nontrivial filter chain.
>
>I've got this working with some minor hacks to 2.0.  Need time to
>generalise/abstract it into a proposal.
>  
>

I like that idea.

And it reminds me of another thing related to filtering that I
think would be valuable (essential, IMHO) for 2.2: redesigning
the input filters so that data is "pushed" through them, instead
of letting each input filter "pull" data from its predecessor.
If we could do this in 2.2.0, it would then be possible to
implement an async, multiple-connections-per-thread MPM
in some future 2.2.x release without breaking the filter API.
Alas, this has been on my to-do list for over a year, and I
havent' yet had time to work on it.

Another aspect of filters that's been problematic in the past
has been ensuring that memory in pool buckets gets freed
at the right time.  This will become even more complicated
if future MPMs have multiple threads handling the same
connection.  (The more I think about this issue, the more
I find myself thinking that we should implement buckets as
java.nio.ByteBuffer objects and let a JVM worry about
reference counting so that we can just worry about web
serving.)

Brian

Re: 2.2 Roadmap?

[Nick Kew <ni...@webthing.com>]

On Sun, 27 Jun 2004, Paul Querna wrote:

> The 2.0 branch was made over 18 months ago, it is time to make another
> stable branch. I believe many people want the AAA changes, and it brings
> even more features to encourage people to upgrade from 1.3.

There's another consideration that could be relevant here: people who
never touch an N.0 software release.  Bump it to 2.3? :-)

> This is only a list from my initial thoughts, please comment and make
> suggestions. I will take the resulting thread and rewrite the ROADMAP
> file.

Smart filtering.  We need much better dynamic configuration of the
filter chain, with processing depending on the headers.  Think an
AddOutputFilterByType that isn't a hackish afterthought, and extend
that to work with more than just Content-Type.  It also fixes the
awkwardness currently involved in ordering a nontrivial filter chain.

I've got this working with some minor hacks to 2.0.  Need time to
generalise/abstract it into a proposal.

-- 
Nick Kew