httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Richards <p.richa...@elsevier.co.uk>
Subject Re: Win32 Progress Report
Date Mon, 05 Aug 1996 15:27:43 GMT
rst@ai.mit.edu (Robert S. Thau) writes:

> Likewise, I think it would be a good idea, now that we're in feature
> phase again, to revive the patch I saw a while ago to separate out the
> OS-dependant parts of shared-memory setup in the scoreboard code from
> the, well... scoreboard parts of it.
> 
> Where Christian loses me is in proposing massive, sweeping changes to
> the organization of the entire code base, rather than simply isolating
> system-dependant functionality as and when it proves useful to do so.
> (That is, the "no #ifdefs" business --- I agree that large ones are,
> in general, useful to avoid, but going through massive contortions to
> avoid small ones for common variations may very well not be worth
> the trouble, and this is best decided on a case-by-case basis).

I think perhaps there's some knee jerk reponses taking place here to
what may be sensible future directions if done correctly.

We don't need to gut the current code and revamp file layout and
everything in one massive re-org phase. We *should* start to move
non-generic code out of the common files and into OS/machine specific
files. That doesn't necessarily mean that there will never be any
ifdef's since obviously basically generic routines that require slight
changes would be done with ifdefs.

Some of the sorts of things I'd like to see would be an intermediate
API between, say, the thread code and the io code which is gated
through OS specific functions which either call native routines or use
Apache supplied routines. This also provides us with the ability to
wrapper any minor OS problems.

e.g. gethostname should be replaced by uname on most systems but not
all work exactly as expected. We should have an apache_gethostname() or
something better named :-) which calls the OS specific function that
does the job best on that platform

i.e.

apache_gethostname -> freebsd_gethostname -> uname

For SCO which apparently has a weird implementation of uname, the
sco_gethostname routine would do some post-processing on the string
returned before passing it up the layers.

This sort of abstraction would make a lot of the complex ifdef'ing
in some places much cleaner and for new ports it's obvious which
routines need to be catered for, either by mapping them to native
functionality or by writing new code.

If these OS specific functions are in separate files the you can remove
one of the function calls by simply having standard function names in
OS specific files and only including the appropriate OS file at compile
time, which is strong reason for re-organising the file layout in that
direction.

i.e.
freebsd.c

apache_gethostname() {
	uname()
}

This wouldn't take long to do and can in fact be done gradually by
first removing those routines that have lots of ifdef's for OS
variations into a file called os.c, as they are, and then the platform
maintainers can migrate their OS's chunks into separate files as they
find the time. At least this first stage would identify those parts of
Apache that are not totally generic.

This is actually something I'm willing to put some effort into.

I think first we need to make a decision about 1.2, I'm seriously
thinking now that 1.2 is holding us up and that we should just move
towards implementing some of these bigger changes right now for 2.0.

Either ditch 1.2 completely or get 2.0 into cvs so we can start on
these bigger issues in parallel with the 1.2 release but I have
serious reservations about doing that since I suspect the result would
be that everyone started doing the fun stuff in 2.0 and 1.2 would be
seriously under resourced.


-- 
  Paul Richards. Originative Solutions Ltd.  (Netcraft Ltd. contractor)
  Elsevier Science TIS online journal project.
  Email: p.richards@elsevier.co.uk
  Phone: 0370 462071 (Mobile), +44 (0)1865 843155

Mime
View raw message