[Cherrypy-devel] RE: Some (initial) patches against 0.8 beta

[Remi D. <re...@ch...>]

> > - About logging: that's something I had on my mind. I think we
> should give
> > the user the option to log messages to screen and/or to file (or no
> messages
> > at all). I'm thinking about 2 new options in the config file:
> > logsToScreen=0|1 and logFile=/tmp/myLogFile
>
> I have no objection to this, but I'd like to be in a position to override
> the CherryPy supplied code if it does not fit my needs.  For
> example, in an
> embedded device one might have a custom API for a circular log
> that sits in
> NVRAM, or under Windows * one might want to put certain messages into the
> Windows event log.

Okay. We can add a new CherryPy special function called "logMessages" whose
default behavior is to log messages to screen and/or to file (according to
the config file) and that can be overwritten by the user (just like the
"onError" special function)

> > - As you may have noticed, I removed the -S option from the command line
> (it
> > was used to specify which service (http) and which mode (threading,
> forking)
> > to use). The reason is that I wanted users to be able to
> specify these at
> > execution time, and not compile time (in other words, you don't have to
> > recompile the server in order to change from threading to forking).
> >
> > - About wrapperPrefixStart.py: Maybe you could tell me what kind of code
> you
> > put in it so I understand the need for it. But anyway, I don't think it
> > should be called "httpStart.py", because it has nothing to do with the
> HTTP
> > service (and it is not related to httpEnd.py).
> >
> > - About wrapperPrefixEnd.py: I understand that the code could
> be different
> > for another service. But in that case, I'd like to take the "no need to
> > recompile" approach. In other words, the service would be
> specified in the
> > config file.
> >
> > - Overall, I have to admit the I don't really like the idea of
> letting the
> > user include arbitrary ".py" files that he writes. If we want to make
> > CherryPy more customizable, we could use the "special
> functions" approach,
> > and let the user define other special functions in the source files
> (".cpy"
> > files).
> >
> > But then again, if you tell me examples of what you need to do
> then maybe
> > I'll realize that what you're proposing is the best solution.
>
> Well perhaps I can achieve my goals by being able to replace the logging
> mechanism, and the parameter passing module (which you've already
> seperated
> out).  Basically, I want to be able to run a CherryPy server in various
> 'embedded' situations where I may have strange logging constraints, or the
> configuration information available in a custom database.

Well, the logging problem can be solved with the solution I propose above.
As for the configuration problem: what kind of configuration information is
available in the database ? socketPort ? If not, then you can just use the
"initServer" special function to get your own options from wherever you
want.

> Once I dust the cobwebs off it, I may also want to run a ThreadedPool
> version of CherryPy, as opposed to the thread-per-request support that the
> ThreadedMixIn provides.  (I was planning to submit this to you anyway).

Okay. This shouldn't be too hard to write. CherryPy already has a
"fixedNumberOfProcesses" option, which is the process equivalent of a
ThreadedPool.

Thanks.

Remi