|
From: Brian M. <bri...@co...> - 2002-12-20 07:02:24
|
Hi Remi,
You wrote:
> - First of all, I created a new mailing list cherrypy-devel and I think we
> should talk on that list.
Great! I signed up today. :-)
> - 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.
> - 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.
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).
> > BTW, the files in lib/*.py have a GPL license in them. Since the code
in
> these files actually gets included in the
> > resultant xxxServer.py, I believe this may cause some people
difficulties.
> Would it be possible to put these files under a
> > more friendly license, while keeping cherrypy.py etc GPL.
>
> You're right. I'll just remove the license from these files. That's what I
> did with the "src/*.py" files, because someone complained about it, but I
> didn't realize that "lib/*.py" files where in the same case :-)
Thanks.
Regards,
-Brian.
|