On Tuesday, February 11, 2003, at 08:31 AM, Geoffrey Talvola wrote:
Sounds fine to me. It might be useful for someone to summarize theMostly it is multi-port. It also cleans up the code a bit to fit Webware conventions. It's not that big a change, though the code cleanup makes it hard to directly compare to ThreadedAppServer.
differences between ThreadedAppServer and NewThreadedAppServer -- it's been
in there so long that at this point, I can't remember what the differences
are :-)
Being multi-port, it makes the Monitor stuff just another protocol, where it's dealt with more as a special case currently. But I haven't even tested the Monitor stuff, so I'm not sure if it works.
I've actually come to feel that the embedded HTTP server is a bigger deal than I thought when I was putting it in. In particular for someone who wants to test Webware -- after trying to set up various other frameworks I've realized what a pain setup is for an evaluation.
Oh, and just because I remembered since it deals with the AppServer, we should also take out AutoReloadAppServer and put that functionality directly into AppServer -- it's kind of a hack that it's a separate class.
Particularly when using the embedded HTTP server, it would also be interesting to create an unthreaded AppServer. This should make it fairly easy to use debuggers on Webware. I haven't looked at the code in a while, but as I remember it ThreadedAppServer was a better basis for an UnthreadedAppServer than was AppServer. That might imply there's something wrong with the class inheritance there.
Ian
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
