httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Gross" <cgr...@eusoft.com>
Subject Re: "Strcasecmp problem"
Date Sat, 03 Aug 1996 17:49:43 GMT


----------
> From: Randy Terbush <randy@zyzzyva.com>
> To: new-httpd@hyperreal.com
> Subject: Re: "Strcasecmp problem"
> Date: samedi, 3. ao{t 1996 17:37
> 
> 
> > I have to admit I liked what I saw when I looked at the threaded
version
> > of the HTTP server.  However, I think that we should adopt an approach
> > that someone mentioned to me in another email.  We should begin to
split
> > Apache into operating system dependent sections. I would be more than
> > happy to port your threaded server to NT, but the fear I see, is that
I
> > will simply delete huge sections of code.  Many calls could be
replaced by
> > native methods of the OS.  If we took an approach where by we created
a
> > hardware layer that moves all calls to a neutral API then porting
would be
> > simple.  Only the hardware layer would need porting.  Then there is
always
> > the solution of using Java.
> > 
> > -- 
> > Christian Gross
> 
> I'm concerned with your comment of "deleting sections of code".
> This also appears to have been the approach in the port to NT done
> by the folks at Sanyo. I don't understand why #ifdef for WINNT does
> not work in this case.
> 
The reason is that ifdef's are really nice if they are only small sections
of ifdefs.  I have noticed that within the core system dependent calls and
higher level calls are quite often in the same file.  By adding a huge
ifdef the code becomes very ugly to look at and expand.

> If we are serious about maintaining an Apache port to NT, IMO we
> need to do it with the same codebase. Those areas needing abstraction
> to OS APIs would be much more apparent if the work could be done
> while leaving the source intact.
> 
Okay here is a suggestion instead of ifdefs we do the following.  The core
calls are something like HTTP_xxxx.c and then modules are mod_xxxx.c.

We split HTTP_xxxx.c to something like 
HAL_NT_xxx.c and then HAL_SOL_xxx.c and for the higher would be
HTTP_xxxx.c and higher yet would be mod_xxx.c

There would be no ifdefs within the HTTP_xxx and mod_xxx.  THere may be
some within the HAL_os_xxxx.c because there could be HAL_bsd_xxx.c  or
HAL_NT_xxxx.c could also be for Windows 95.  This way all code would be
still available and if one was to work on a platform they would not need
to look at all of the code that is not required.  As well I think that
with an approach like this we can take advantage of all nice aspects of
the OS.  For example in your threaded Apache you wrote a threaded library,
which is required on platforms like Linux, but not needed on platforms
like NT or Solaris.  Here is a suggestion, since your threads are an
abstraction maybe we could move this layer to the HAL and it would be part
of the specification.  So native threads would be adapted to this library
of calls.  As well could we make all calls to the HAL using something like
HAL_xxxx etc.  

So am I with it or out in left field????

-- 
Christian Gross
euSOFT
Phone 41.1.492.7827
Fax 41.1.492.7757
http://www.eusoft.com
cgross@eusoft.com


Mime
View raw message