Ian Bicking wrote:
Bigger deal in what way, as in more dificult to get right? Or as in more important to an evaluator?On Tuesday, February 11, 2003, at 08:31 AM, Geoffrey Talvola wrote:Sounds fine to me. It might be useful for someone to summarize the
differences between ThreadedAppServer and NewThreadedAppServer -- it's been
in there so long that at this point, I can't remember what the differences
are :-)
Mostly 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.
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.
Agreed.
I found several areas that it looked like the inheritence structure was a little off. Although it might just be a stylistic thing. I believe that base classes should define (even if unused) all of the properties that are expected to be known in the base-class module. An example is that HTTPRequest has .setTransaction() and .transaction(), while Request() has .clearTransaction().
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.
If a Request always has a transaction then the set and get methods belong in Request().
How should we procede so that we don't stumble over each-other? Some changes like what you suggest regarding re-ordering methods have a high-liklihood of generating conflicts.
Should we just announce "Hey, I'm working in this...." and then outline what we plan to do there, and what files and such we plan to be altering? Is that too loose of a control?
-Stuart-
-------------------------------------------------------
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
