Re: 1.3/2.0

[Randy Terbush <ra...@zyzzyva.com>]

Wow! Hope your doing Ok in you flamesuit. :-) Very little response 
to this...

Your argument is well stated and I must agree that one of the 
advantages this group has had from the beginning has been the 
ability to move things forward quickly. 1.2 showed evidence of 
getting a bit bogged down by I'm not sure what.

To be quite honest, I'm not that bent on threading and defer those 
issues to those of you that are much more qualified to address the 
performance and API issues. I personally have the following list of 
items that I would like to start working on to pursue my personal 
interests. 

* proxy
* GUI API
* SNMP - could apply to GUI
* SQL applications

This seems to sync well with Brian's shortlist below and I would 
support a refocusing to see if we can take some smaller steps 
toward the 2.0 goal.


> 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
>