2.0: process model design

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

Ok, here we go:

http://www.arctic.org/~dgaudet/apache/2.0/process-model

Discuss, argue, rant, rave, comment. 

Dean

Re: 2.0: process model design

[Alexei Kosut <ak...@leland.Stanford.EDU>]

On Sat, 22 Nov 1997, Igor Tatarinov wrote:

> > That being said, I think the code should be made more C++-friendly. By
> > that I mean it should compile with a C++ compiler, which it does not now
> > (namespace problems). The header files should contain extern "C"
> > declarations and the like, etc... And it is my plan that, when I finally
> > get around to writing up my spec for the Apache 2.0 module API, it will be
> > C++-saavy, so that you can write modules in C++, and pretend you are
> > dealing with objects (though you aren't, really).
> 
> I am not sure it's really worth it. Those who want to modify Apache
> will probably use a C compiler anyway. Other users can download 
> binaries.

Actually, given my ideas for the Apache 2.0 module API (go back and read
the  Apache mail archives; http://dev.apache.org/mail/), C++ support isn't
that tough. In fact, it's not all that bad now. The part of the module API
that deals with the request is very nearly OO. request_rec, server_rec,
connection_rec, BUFF and the like behave very much like objects would.

*shrug*

-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
   Stanford University, Class of 2001 * Apache <http://www.apache.org> *

Re: 2.0: process model design

[Igor Tatarinov <ta...@prairie.NoDak.edu>]

Alexei Kosut wrote:
> 
> On Sat, 22 Nov 1997, Igor Tatarinov wrote:
> 
> > How about doing 2.0 in C++? Many things would be so much nicer then.
> 
> We've discussed this. I have nothing against C++, but I think there are
> several reasons that we should stick with C (in no particular order):
> 
> 1) C++ compilers are much harder to come by than C compilers on a given
>    platform. Nearly any Unix system will have a C compiler available, with
>    mostly working ANSI C libraries. Most Unices will not have C++
>    compilers by default, and if they do, they are often broken. If we
>    moved to C++, we'd have to require that those using it download a C++
>    compiler (gcc, most likely), and possibly some C++ library (now that
>    there is finally an ISO C++ standard, this might become easier).
> 
>    Apache wants to run and support as many OSes as possible, out of the
>    box. C++ makes this much harder to do.

I can argue against that. Most users do not probably need the source 
code. so binary execs would be enough.
 
> 2) Apache is written in C. Regardless of what we keep talking about,
>    Apache 2.0 will not be a ground-up rewrite. 
> 
>    If we moved to C++, Apache would have to be rewritten completely to be
>    object-oriented, or there's really no point. And that would involve a
>    lot more work than we're really prepared to give it, I think.

I can agree with that.
 
>    In addition, I suspect many Apache developers (myself included) are not
>    as familiar with C++ as they are with C. Because Apache is a volunteer
>    organization, and we have to training budget, this may be a good enough
>    reason to stick with C.

If this is true, I withdraw my idea. It's well known that to reap the 
benefits of OOP one has to spend much more time in design than in the 
traditional approach. Of course, experience helps a lot here.
 
> That being said, I think the code should be made more C++-friendly. By
> that I mean it should compile with a C++ compiler, which it does not now
> (namespace problems). The header files should contain extern "C"
> declarations and the like, etc... And it is my plan that, when I finally
> get around to writing up my spec for the Apache 2.0 module API, it will be
> C++-saavy, so that you can write modules in C++, and pretend you are
> dealing with objects (though you aren't, really).

I am not sure it's really worth it. Those who want to modify Apache
will probably use a C compiler anyway. Other users can download 
binaries.

igor

Re: 2.0: process model design

[Alexei Kosut <ak...@leland.Stanford.EDU>]

On Sat, 22 Nov 1997, Igor Tatarinov wrote:

> How about doing 2.0 in C++? Many things would be so much nicer then.

We've discussed this. I have nothing against C++, but I think there are
several reasons that we should stick with C (in no particular order):

1) C++ compilers are much harder to come by than C compilers on a given
   platform. Nearly any Unix system will have a C compiler available, with
   mostly working ANSI C libraries. Most Unices will not have C++
   compilers by default, and if they do, they are often broken. If we
   moved to C++, we'd have to require that those using it download a C++
   compiler (gcc, most likely), and possibly some C++ library (now that
   there is finally an ISO C++ standard, this might become easier).

   Apache wants to run and support as many OSes as possible, out of the
   box. C++ makes this much harder to do.

2) Apache is written in C. Regardless of what we keep talking about,
   Apache 2.0 will not be a ground-up rewrite. AFAIK, we've talked about
   rewriting/enhancing to the point of unrecognizability the following
   items:

   a. The configuration system
   b. The process/thread model.
   c. The module API
   d. The I/O system
   e. The OS-specific code

   That leaves a large part of the server intact. I'm thinking
   specifically of http_request.c and http_protocol.c. I would personally
   not want to rewrite http_protocol.c. Many billions of man-hours (I'm
   exaggerating) have gone into making it work right. And it does, for the
   most part.

   If we moved to C++, Apache would have to be rewritten completely to be
   object-oriented, or there's really no point. And that would involve a
   lot more work than we're really prepared to give it, I think.

   In addition, I suspect many Apache developers (myself included) are not
   as familiar with C++ as they are with C. Because Apache is a volunteer
   organization, and we have to training budget, this may be a good enough
   reason to stick with C.

That being said, I think the code should be made more C++-friendly. By
that I mean it should compile with a C++ compiler, which it does not now
(namespace problems). The header files should contain extern "C"
declarations and the like, etc... And it is my plan that, when I finally
get around to writing up my spec for the Apache 2.0 module API, it will be
C++-saavy, so that you can write modules in C++, and pretend you are
dealing with objects (though you aren't, really).

But as for Apache itself, I think C is still the path we want to continue
down.

-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
   Stanford University, Class of 2001 * Apache <http://www.apache.org> *

Re: 2.0: process model design

[Igor Tatarinov <ta...@prairie.NoDak.edu>]

Dean Gaudet wrote:
> 
> Portability wouldn't be nicer.  We currently have platforms that don't use
> gcc.  We also have to deal with g++ versus microsoft c++ versus cfront
> issues.
> 
> What in my process-model screams "C++"?  Nothing looks like it to me.  I
> can see C++ arguments in relation to other details of the API though...
> like modules.
> 
> Dean

I meant general advantages of the OO approach. The current http_main.c
for example contains probably about 100 functions which makes it tough
to even look thru it (and it has to be modified!). If separate entitie
(scoreboard, connection, thread, etc) were implemented as classes, all 
interfaces and relations between pieces of code would be clearer. Of 
course, the design stage becomes harder.

BTW, there is a freeware C++ library called ACE which basically provides
nice OO-style wrappers for many UNIX/NT mechanisms. I haven't tried it
myself but it seems pretty good.

igor

Re: 2.0: process model design

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

Portability wouldn't be nicer.  We currently have platforms that don't use
gcc.  We also have to deal with g++ versus microsoft c++ versus cfront
issues.

What in my process-model screams "C++"?  Nothing looks like it to me.  I
can see C++ arguments in relation to other details of the API though...
like modules.

Dean

On Sat, 22 Nov 1997, Igor Tatarinov wrote:

> Dean Gaudet wrote:
> > 
> > Ok, here we go:
> > 
> > http://www.arctic.org/~dgaudet/apache/2.0/process-model
> > 
> > Discuss, argue, rant, rave, comment.
> > 
> > Dean
> 
> How about doing 2.0 in C++? Many things would be so much nicer then.
> 
> igor
> 

Re: 2.0: process model design

[Igor Tatarinov <ta...@prairie.NoDak.edu>]

Dean Gaudet wrote:
> 
> Ok, here we go:
> 
> http://www.arctic.org/~dgaudet/apache/2.0/process-model
> 
> Discuss, argue, rant, rave, comment.
> 
> Dean

How about doing 2.0 in C++? Many things would be so much nicer then.

igor