Mailing List Archive

Sigh... all output from modules already goes through rprintf(). The
performance hit is minuscule and not worth considering. If you're really
worried about this, check out the way includes work --- the rputc() business
there is even nastier, but profiles appear to show it still isn't much
worth worrying about.

BTW, I've spent a bit of time recently thinking over the "OS-independance"
idea, and I'm afraid I'm beginning to get a little skeptical about it...
essentially *all* of several fairly large source files is very OS-dependant,
as are several of the modules, and a whole lot of OS's, including at least
OS/2, apparently do come with at least minimally acceptable Posix wrappers.
It might be best to pause before going through this to figure out what
systems you want to be porting *to*, and what would be the least-cost way
of doing that, rather than going through a whole lot of what might be
unnecessary work.

rst

[os independance]
> fclose, fflush, fprintf, etc. are replaced (when used on a connection) with
> os_conn_fclose, etc. This can be done in such a way as to have no performance
> impact on the existing system, using #defines.

Mmm, will it be that much of a performance hit to make unix version of
os_conn_printf something like:

int
os_conn_printf( xxx ) {
printf( xxx );
};

I'm not certain that the performance hit of a layer of indirection and
function calling will be that much of a problem.

> Also, does anyone support/object to the idea of incorporating such changes?

I hate defines. But I hate warm beer too.

> Ben.

Ay.

My question is: why is OS independence desirable for a server?
I mean Unix + Vax + Mac + Win ... instead of just Unix.

Seriously, at some point we will want to profile the hell out of the
beastie and streamline the server operations as much as possible.
Trying to do that with abstract interfaces to system functions just
doesn't work. Instead, I'd recommend modularizing the server into
units that can be either OS-dependent or OS-independent. Those that
are OS-independent can be shared and the rest kept as separate
versions per OS.

We already have most of the modularity -- we just haven't applied it
to things like the URL <-> filespace mapping. However, things that
will remain OS-dependent are pervasive: process control, uid handling,
socket handling, filespace operations, memory allocation, scoreboard
control, CGI, and even the configuration file(s) -- in other words,
just about everything Apache does that isn't in an optional module.

Now, I think it would be an interesting exercise to see how much of
the server can be made OS-independent, as long as it doesn't include
Mac and Windows*. I know that those two would be hell, and there just
isn't any value in doing the port (Chuck and Bob have already covered
those platforms with servers designed specifically for those OSes).
I'm sure someone will try anyway, but it won't be going in the core
code unless it has no impact on performance for other platforms.

In any case, I think it would require that the whole server development
be forked, and I don't think we are ready for that yet. Instead, as
soon as 1.0 is shipped, I'd like to run an auto-formatter through the
source code and then get the entire group to work on nothing but
documentation and comments for a week.

Hmmm, I guess what we should do is create a list of everything we
want to do after 1.0, and then decide what the group priorities
should be. It's possible that everyone will want to go off and work
on private versions for a while, or maybe the opposite. I don't know.

.....Roy

> I don't know.

Feels good dun't it.

> .....Roy

Ay.

>
> Sigh... all output from modules already goes through rprintf().

All modules, that is, except http_protocol.c itself! Would anyone object if
I fixed that?

> The
> performance hit is minuscule and not worth considering. If you're really
> worried about this, check out the way includes work --- the rputc() business
> there is even nastier, but profiles appear to show it still isn't much
> worth worrying about.

Cool. I just wanted to formulate a way that had _no_ performance hit over
the current implementation, but I'm fine with a minimal performance hit
instead. In fact, taking over rprintf would mean no performance hit.

>
> BTW, I've spent a bit of time recently thinking over the "OS-independance"
> idea, and I'm afraid I'm beginning to get a little skeptical about it...
> essentially *all* of several fairly large source files is very OS-dependant,
> as are several of the modules, and a whole lot of OS's, including at least
> OS/2, apparently do come with at least minimally acceptable Posix wrappers.
> It might be best to pause before going through this to figure out what
> systems you want to be porting *to*, and what would be the least-cost way
> of doing that, rather than going through a whole lot of what might be
> unnecessary work.
>
> rst

--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk
A.L. Digital Ltd,
London, England.

Now, I think it would be an interesting exercise to see how much of
the server can be made OS-independent, as long as it doesn't include
Mac and Windows*. I know that those two would be hell, and there just
isn't any value in doing the port (Chuck and Bob have already covered
those platforms with servers designed specifically for those OSes).

But is there any value in ports to a platform other than these? I don't
see any virtue in turning the code inside-out to capture the enormous
OpenVMS user base (and that's one of the ones with a Posix binding anyway).
To first approximation, Mac and Windows are the only OSes with enough of
a user base to be worth the trouble. (A second approximation would include
large server mainframe OSes, but the people who use those probably would not
be interested in freeware anyway).

rst

All modules, that is, except http_protocol.c itself! Would anyone object if
I fixed that?

Um.... that's not a module. I reserve that term for code which relates
to the server core only through the module interface (the mod_* files).
The http_foo stuff is the server core, and plays by different rules.

That said, this would be a perfectly useful cleanup...

rst

Oooops... sorry, Garey. I didn't mean to exclude OS/2 (particularly since,
as you say, the port is already done) --- but since you handled it with
a Posix emulator for the most part (except for the CGI stuff), I had it
mentally classified as enough like Unix to be handled using only the Unix-oid
portability approaches which we've been using already. Sorry about the
confusion.

rst

On Mon, 16 Oct 1995 08:51:11 -0400 you wrote:

> Now, I think it would be an interesting exercise to see how much of
> the server can be made OS-independent, as long as it doesn't include
> Mac and Windows*. I know that those two would be hell, and there just
> isn't any value in doing the port (Chuck and Bob have already covered
> those platforms with servers designed specifically for those OSes).
>
>But is there any value in ports to a platform other than these? I don't
>see any virtue in turning the code inside-out to capture the enormous
>OpenVMS user base (and that's one of the ones with a Posix binding anyway).
>To first approximation, Mac and Windows are the only OSes with enough of
>a user base to be worth the trouble. (A second approximation would include
>large server mainframe OSes, but the people who use those probably would not
>be interested in freeware anyway).

How about OS/2 (9 million users) since the port is already done.


Garey Smiley
SoftLink Services
garey@slink.com
http://www.slink.com/
(216)848-1312 FAX/Data(216)699-4474

On Mon, 16 Oct 1995 09:50:26 -0400 you wrote:

>Oooops... sorry, Garey. I didn't mean to exclude OS/2 (particularly since,
>as you say, the port is already done) --- but since you handled it with
>a Posix emulator for the most part (except for the CGI stuff), I had it
>mentally classified as enough like Unix to be handled using only the Unix-oid
>portability approaches which we've been using already. Sorry about the
>confusion.

No problem :-) My major goal was to make it transparent as possible to
the base code, so classify it any way you please.


Garey Smiley
SoftLink Services
garey@slink.com
http://www.slink.com/
(216)848-1312 FAX/Data(216)699-4474

> But is there any value in ports to a platform other than these? ...

My experience is that, when it comes to porting, value is in the eyes
of the porter. If the only computers in your lab run some butt-ugly OS,
then its quite likely the Apache/butt-ugly port will soon follow.
The question really is how much effort/emphasis will be placed on
making the core server easy to port to those obscure platforms, not
whether someone will try.

Speaking of which, when are you going to port Apache to Thinking
Machines' OS? It's about time that CM5 was put to something useful. ;-)

....Roy

p.s. just thinking about all the cool things you could do with
the blinky lights.... it would put wwwstat to shame.

On Mon, 16 Oct 1995, Robert S. Thau wrote:
> Now, I think it would be an interesting exercise to see how much of
> the server can be made OS-independent, as long as it doesn't include
> Mac and Windows*. I know that those two would be hell, and there just
> isn't any value in doing the port (Chuck and Bob have already covered
> those platforms with servers designed specifically for those OSes).
>
> But is there any value in ports to a platform other than these? I don't
> see any virtue in turning the code inside-out to capture the enormous
> OpenVMS user base (and that's one of the ones with a Posix binding anyway).
> To first approximation, Mac and Windows are the only OSes with enough of
> a user base to be worth the trouble.

I would support as much effort as it took to support all Unices, OS/2 and
NT. I think the changes to go to Mac and Windoz are simply too great to
keep the server a lean beast - I fear we would end up looking like
www-lib code :)

Another tack, of course, is to rewrite apache into java...

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/