I am working out the details of a patch I discussed about a month ago
that would allow the ThreadedAppServer to be subclassed, and I wanted to
bounce the ideas out on the list before I was finished to see if there
was any further feedback or interest. My goal would be of course to see
this get into CVS.
Basically I am looking ThreadedAppServer run() and main() taking an
AppServerClass argument. The default would be of course
ThreadedAppServer to prevent breaking anything.
Launch would allow loading a module other than from WebKit, and then
invoke the main() function within that module to start the appserver of
that module.
The bulk of the run() function will be moved into a run() method on
ThreadedAppServer() which allows it to be overridden via subclassing and
makes it conveniently available to a subclassed AppServer.
For compatibility, the ThreadedAppServer.run() function would then
basically look like:
def run(useMonitor=0, workdir=0, serverClass=ThreadedAppServer):
global server
try:
server = None
server = serverClass( workDir )
server.run( useMonitor=useMonitor )
except
...
The remaining part of the run function gets added to a run method on
ThreadedAppServer. This allows a subclass to alter the run method.
The ThreadedAppServer.main() function continues as it has, but takes an
argument for the serverclass which it then passes in to the run method.
The reason being that a derived module may not want to alter the
behavior of main() so it can just call
ThreadedAppServer.main(args,serverClass=MyAppServer)
I'm a little concerned about the main()/run() interface in
ThreadedAppServer. The convention for estension seems to be decode new
options in main() and then add new function parameters to run(). This
breaks for example the call that NewThreadedAppServer.main() makes to
AppServer.stop() (reference my previous message)
Perhaps we should have a command object that contains all parsed options
in an easily extracted manner. That could then be passed from main() to
run, and to stop. Although another alternative would be to move over
completely to the Configurable.addCommandLineSetting() approach, and
take the single word items like "monitor" and "stop" and construct
settings like "Command.monitor=1" and "Command.stop=1" which could be
parsed later.
I looked at the idea of creating static methods on the appserver, but
that doesn't work with inheritence, and I had run into problems with
compatibility and the MixIn capability which appears to be more
frequently used.
In case it isn't obvious, the reason for wanting to make an AppServer
subclassable, is that it makes it much simpler to modify the AppServer
behavior from a users perspective if you are trying to use a static
"released" Webware installation. MixIn is pretty cool, but there are
some circumstances where that doesn't work. Mainly that for replacing
some functions, you need to do your MixIn prior to loading and starting
the AppServer.
Any comments or ideas? Is this sounding too complicated? (well more
complicated than the current Launch/main/run/AppServer model?)
-Stuart-
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
