1.3/2.0

[Brian Behlendorf <br...@organic.com>]

On Thu, 12 Jun 1997, Rob Hartill wrote:
> I can't see us finished with the 2.0 design discussions before August
> of this year.

*sigh*.  

I am going to be blunt, I apologize in advance.  

I think people are going a bit overboard in 2.0 design discussions
regarding just how much of a revamp this should be.  I have followed
the arguments regarding the API - that the named phases is a difficult
concept since "names" are inconsistantly applied.  That there are
performance problems if we double the number of phases, though Dean's
patches might address that.  I honestly respect that many people are
interested in experimenting with something new; and that Apache,
because it's not being driven by a corporate entity with P&L
statements to think about, should be free to explore.  But I think
taking three months to lay out the design of 2.0 is excessive.  

Why?  Because making the server multithreaded just isn't going to be
that hard.  The API we have today is not going to have a problem with
it; RST designed it from the beginning to be thread-safe, though
certainly some modules written under it are not thread-safe.  The
configuration file syntax is ugly, but with some limited changes I
think we can make it much cleaner.  

To be convinced otherwise, I need to see evidence that the current
API, with some added phases, is insufficient to handle the types of
applications we as web developers want to do.  For example, I really
really want to be able to feed the output of one module (say mod_cgi)
through another module (say mod_include).  I know with threading and
sfio or bstdio we'll be able to do that.  Can the API handle it?  Why
or why not?  

I think the majority of us here on the list are not here for purely
personal reasons; we are working on this at least partially on company
time, and have a duty to produce something which is worth the extra
money being spent on it.  When other really good servers (in their
opinion :) are being given away for free, and are becoming fairly
advanced, it becomes more and more difficult to justify expenditure of
resources.  *Particularly* when it takes 9 months for a minor-number
release.  So, I have to listen to what my company needs from the
server, and we also have an obligation to hear what the user community
wants.  They want, among other things:

1) a port to NT!
2) a GUI
3) a Java interface
4) a multithreaded server

A more capable API is there, but it is not nearly as high a priority.

As the most recent [STATUS] mailing shows, there is a lot we could do
even if we just wanted to make the current code base better, without
going for broke for the above three features.

My point in all this is: many of us cannot afford to make Apache
a testbed for deep new ideas about server technology.  Even RST's
Shambala was not a deep test of anything *new*, but simply a good
design, and I think it has largely stood the test of time.

Conclusion: I will strongly suggest that for 2.0 we keep the current
API, enhancing it with new "phases", perhaps renaming the phase to
speak more about what happens between them than what they are for, and
put in some enhancements to address performance problems.  


In Sept. of 1996 I dashed off a "project plan", at

  http://dev.apache.org/project-plan.html

This seemed to speak for the consensus of the group.  I have made a
stab at revising it:

  http://dev.apache.org/project-plan-new.html

I have also included in there a proposed schedule.  Yes, it is
aggressive.  However I believe this summer we will have a number of
development resources available, and with some good planning we can
get some more.  There are literally hundreds of people chomping at the
bit for NT; and plenty more who can help with threading work for 2.0.  
I also believe that if some of us aren't aggressive about it then it
won't end up happening.  

I've donned my asbestos suit, I'm ready for your flames.

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  www.apache.org  hyperreal.com  http://www.organic.com/JOBS

Re: 1.3/2.0

[Rob Hartill <ro...@imdb.com>]

On Sat, 14 Jun 1997, Dean Gaudet wrote:

> On Fri, 13 Jun 1997, Rob Hartill wrote:
> > This is based on the time it took to go from 1.1 to 1.2. I think we could
> > have set ourselves higher targets considering the time that elapsed.
> 
> I think we did reach a higher target -- we fixed an awful lot of subtle
> long standing bugs. We vastly improved the robustness of the server ... 
> and we learned a lot about what we need to fix in the long term.  The last
> five months has been painfully long but I think the product really
> benefitted from it. 

I agree with all of that but I think a lot more could have been achieved
in the same timeframe had we known how long it was going to take and then
planned things acordingly.

--
Rob Hartill                              Internet Movie Database (Ltd)
http://www.moviedatabase.com/   .. a site for sore eyes.

Re: 1.3/2.0

[Dean Gaudet <dg...@arctic.org>]

On Fri, 13 Jun 1997, Rob Hartill wrote:
> This is based on the time it took to go from 1.1 to 1.2. I think we could
> have set ourselves higher targets considering the time that elapsed.

I think we did reach a higher target -- we fixed an awful lot of subtle
long standing bugs.  We vastly improved the robustness of the server ... 
and we learned a lot about what we need to fix in the long term.  The last
five months has been painfully long but I think the product really
benefitted from it. 

Dean

Re: 1.3/2.0

[Rob Hartill <ro...@imdb.com>]

On Thu, 12 Jun 1997, Brian Behlendorf wrote:

> On Thu, 12 Jun 1997, Rob Hartill wrote:
> > I can't see us finished with the 2.0 design discussions before August
> > of this year.
> 
> *sigh*.  
> 
> I am going to be blunt, I apologize in advance.  
> 
> I think people are going a bit overboard in 2.0 design discussions
> regarding just how much of a revamp this should be.

I disagree, basically because I'd like to see 2.0 be a long term project
and not a quick attempt to force 1.2 to do the things it currently cannot.

This is based on the time it took to go from 1.1 to 1.2. I think we could
have set ourselves higher targets considering the time that elapsed.

My worry is that the release cycle will be long regardless of the
amount of work that goes into it. If we're going to spend 10+ months
on a release lets at least humour some of the big wish list items
early on.

I'm pretty much satisfied with 1.2 + mod_perl because it does
everything I want it to. I'm not desperate for any new API tweaks,
so I'm looking further into the future.


--
Rob Hartill                              Internet Movie Database (Ltd)
http://www.moviedatabase.com/   .. a site for sore eyes.