Ian Bicking wrote:
> 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
>> 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.
Bigger deal in what way, as in more dificult to get right? Or as in
more important to an evaluator?
> 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
> 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.
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().
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?