Re: minor features and changes

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

> On Sun, 8 Jun 1997, Rob Hartill wrote:
> 
> > On Sat, 7 Jun 1997, Marc Slemko wrote:
> > 
> > > There are various little features and changes that have been backing up
> > > for an awfully long time.  While we figure out a path for the major
> > > changes that are going to be made in 1.3 and for 2.0, I don't see why
> > > development shouldn't move ahead.
> > > 
> > > Any objections to me (and hopefully others...) starting to get moving
> > > again on patches and changes that are relatively minor things compared to
> > > the API and threads and abstraction related? 
> >  
> > Have we decided on a path ?
> > 
> > it's all terribly confusing from the various threads going on.
> > 
> > My preference..
> > 
> > Develop 1.3 and 2.0 in parallel and be prepared for emergency 1.2.X's.
> > 
> > 2.0      major revamp
> > 1.3      1.2 + features - to live as long as there's support for it.
> > 1.2.x    important bugfixes only - no features.
> 
> My problem is that this makes it even harder for 2.0 to ever happen.  For
> the longest time, the plan for 2.0 has included multithreading, NT, and an
> improved API.  Now much or most of that is perhaps going into 1.3.  I have
> not followed the NT discussions, but I am wondering if 1.3 should be
> either a make-do NT port (ie. minimal changes to have a reasonably
> functional server on NT without rewriting more code than necessary) or 1.3
> should be skipped and just push for 2.0. 
> 
> I am concerned that an attempt at a "quick" 1.3 release for NT will end up
> taking just as long as going for 2.0 would and still leave things somewhat
> fragmented. 

It is my understanding that Ben has in hand an integrated NT source 
that actually works. I don't get the impression that we are talking 
about a long time to get this integrated. 

Secondly, I think that a major-minor revision would be appropriate 
for the addition of the NT code base.

> What about a 1.2-NT release?  How much of the current development group is
> interested in NT work?  Do most people belong to one group or the other?
> Would it be better for those who want a NT release soon to do it in a
> seperate, not-for-unix tree as opposed to an integrated 1.3?
> 
> I do not object to work going on in the pre-2.0 area while 2.0 is begin
> developed; in fact I support that and think the extra effort of
> integrating changes not related to the API or threading, etc. is easily
> managed.

Re: minor features and changes

[Paul Sutton <pa...@ukweb.com>]

On Sat, 7 Jun 1997, Randy Terbush wrote:
> It is my understanding that Ben has in hand an integrated NT source 
> that actually works. I don't get the impression that we are talking 
> about a long time to get this integrated. 

Do you mean Ambarish's port? As far as I know there are two major NT ports
currently available... one by Ambarish Malpani for compiling with MSVC
into a native Windows app, and one by maruzz@matrice.it for use with
cygwin. The later is a relatively minor set of changes, effectively just
adding a new OS target for conf.h (because cygwin provides a very
Unix-like environment, unlike Win32). I expect we could merge the cygwin
changes into the head without problems now. 

However, we are mainly discussing the first port. The latest available
version is based on 1.2b10, and compiles and works pretty well on Windows
95 and Windows NT (I have some minor problems, but they may be due to my
setup rather than the port).

I guess we could release Apache 1.2 NT in the very near future, as an
alpha or initial test version. This not an issue.

But I would be concerned about attempts to "integrate" the NT port at this
stage into the head development. In order to work, the NT port makes
several fundamental changes to the code, and although these are
conditional on #ifdef WIN32 sections so will not affect Unix users that
much, once we commit them it will be more difficult to back-track and
extract them into a proper abstraction.

As an example, the call_exec function in the module API currently does not
return (it does an exec*()). In the NT port it does a spawn*() and returns
the child PID. So all modules which use call_exec (including mod_cgi,
mod_include, mod_rewrite) have to be updated with more #ifdef WIN32
sections. These leads to a large number of changes throughout the code.
This will make the job on module writing more complex, and testing very
difficult (since a typical module writer on Unix may not have access to MS
operating systems and MSVC, for example). So in a merged Apache for Unix
and NT I would like to see a *consistent* module API interface (it may
well be that call_exec functionality has to be updated to work more like
the NT version, but at least it would be consistent across all platforms). 
There are other cases similar to this (socket functions, timeouts,
signals, etc). 

So I would prefer if we held off integrating the Unix and NT code until we
can do it properly, as part of the 2.0 development process (which would of
course also rewrite much of the module API, so adding in extra changes to
support os abstraction would not be a major issue). For now, develop
Apache 1.3 in parallel for Unix and NT. 

//pcs