NT to do list

[Ben Hyde <bh...@gensym.com>]

In an attempt to get a list started this is what falls
out of my head if I shake it.

  Install 
    N flavors mean N things to support and N things
      to decide the content of.
    Getting it all into CVS
    
  Instructions on running the server when the customer doesn't
  have admin. privs (i.e. most intranet PC users).

  Replacement for signal handling.  Paul's recent
  changes might cover this, when I glanced at the original
  they seemed to provide an named event that could be zapped 
  to inject the equivalent of signal, but not a tool to
  do the zapping.  - Doc to explain mechinism required.

  Shaking out the Service interface.

  Doc so one can say "RTFM", for oh so many tedious details
  that a pure PC person would be confused by.

  The mutex should be critical-regions, since the current
  design is creating a mess of OS calls that are unnecessary.

  Files are not being MMAP'd to send them, it maybe that
  "TransmitFile" would be best.

  Some performance testing is probably necessary :-).

  The situation with http-main.c being so divergent between
  the Unix and the Windows cases concerns me.  The patch
  to give Window's a pid log file is typcial of the
  kinds of things I assume are falling thru the cracks.

  A CGI example is sorely needed.  Buffering...

  I recall thinking, but don't recall specifics, that Paul's
  "[PATCH] a bundle of multithreading changes" was the first
  of a series.

  The doc explaining how to build from source needs work, or
  at least I had a hell of time getting it up and working.
  Oh, and possibly a pointer to a page explaining how to 
  setup CVS et. al. would be good.

  Mod_example isn't multithreaded yet.

  Doc and/or code needs to address the serialing of thread
  access to modules issue.

  I doubt that waking up every second is the "right" solution
  to the it won't shutdown problem.

  Of course the build doesn't link at this point.

  Doc, and understand, the "which user" is running the server.
  I suspect this involves some code revisions.

  Make tee shirts.

  mod_isapi?

  PRs, isn't there one about file handle leaks?

  What to name the files should take a gross of messages to
  resolve.

  Doc about short/long file name handling.

 - ben
---
"The function of planning is so we all know the
plan from which we are deviating."

Re: NT to do list

[Marc Slemko <ma...@worldgate.com>]

Oops, don't double click in the wrong place in MS's infoviewer or it
crashes.

I can't send the whole bit since it is copyrighted, but:

BOOL TransmitFile(     SOCKET hSocket, 
    HANDLE hFile, 
    DWORD nNumberOfBytesToWrite, 
    DWORD nNumberOfBytesPerSend, 
    LPOVERLAPPED lpOverlapped, 
    LPTRANSMIT_FILE_BUFFERS lpTransmitBuffers, 
    DWORD dwFlags 
   ); 
 
It isn't clear if it starts sending from the current position in
the file or if it goes to the start before sending... I would hope
it would send from the current position, but...



On Fri, 9 Jan 1998, Dean Gaudet wrote:

> 
> 
> On Fri, 9 Jan 1998, Ben Hyde wrote:
> 
> >   Files are not being MMAP'd to send them, it maybe that
> >   "TransmitFile" would be best.
> 
> The buff interface doesn't directly support this... so it'll require a
> hack.  I'm not sure the cleanest way to do it.  I think there should be a
> btransmit_file() function which implemented everything the best way on all
> platforms.  But to do that right we need to know the details of the
> TransmitFile() interface, and should probably look at SGI's similar
> function in IRIX... and Solaris'. 
> 
> Please tell me TransmitFile takes two descriptors and an amount to
> transfer. 
> 
> >   The situation with http-main.c being so divergent between
> >   the Unix and the Windows cases concerns me.  The patch
> >   to give Window's a pid log file is typcial of the
> >   kinds of things I assume are falling thru the cracks.
> 
> I'd like it to be split up into multiple files, but I know you disagree. 
> I fear a #ifdef zoo worse than what we already have.  I think that both
> windows and unix should share the same main(), which should direct things
> like initializing alloc, parsing the command line/whatever, and parsing
> the config file.  Then it should proceed through a standard main process
> initialization, followed by calls into the win32 and unix specific code
> which start the daemons. 
> 
> I think the win32 and unix specific code should be in distinct files. 
> They present an API to the external world, but they don't really share a
> lot of stuff in common except for initialization and re-initialization. 
> 
> >   Make tee shirts.
> 
> ;)
> 
> Dean
> 

Re: NT to do list

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

On Fri, 9 Jan 1998, Ben Hyde wrote:

>   Files are not being MMAP'd to send them, it maybe that
>   "TransmitFile" would be best.

The buff interface doesn't directly support this... so it'll require a
hack.  I'm not sure the cleanest way to do it.  I think there should be a
btransmit_file() function which implemented everything the best way on all
platforms.  But to do that right we need to know the details of the
TransmitFile() interface, and should probably look at SGI's similar
function in IRIX... and Solaris'. 

Please tell me TransmitFile takes two descriptors and an amount to
transfer. 

>   The situation with http-main.c being so divergent between
>   the Unix and the Windows cases concerns me.  The patch
>   to give Window's a pid log file is typcial of the
>   kinds of things I assume are falling thru the cracks.

I'd like it to be split up into multiple files, but I know you disagree. 
I fear a #ifdef zoo worse than what we already have.  I think that both
windows and unix should share the same main(), which should direct things
like initializing alloc, parsing the command line/whatever, and parsing
the config file.  Then it should proceed through a standard main process
initialization, followed by calls into the win32 and unix specific code
which start the daemons. 

I think the win32 and unix specific code should be in distinct files. 
They present an API to the external world, but they don't really share a
lot of stuff in common except for initialization and re-initialization. 

>   Make tee shirts.

;)

Dean