Chuck Esterbrook wrote:
> Jay Love wrote:
> > I think I may have come to agree with you on the issue of assigning to
> > instance variables in Servlet. Maybe we should take out those places
> > where we assign to self and just pass transaction to everything.
> > Agree?
> Agreed. But I'm curious: what made the decision for you?
> > Now, more contentious issues.
> > First, in Application.createServletforTransaction, let's move the cache
> > checks up to the top, no need to get the factory if it's cached.
> Woops. Good catch.
> > Also, in createServletForTransaction, we need to check that the file
> > exists.
> Yeah, I hadn't gotten around to this. Also, I want to pick up the extension automatically. If the URL has "/Hello", then Hello.py or Hello.psp should get picked up. An error if there are two Hello's. Then if you want to switch between a "normal" servlet and a PSP, you can do so without breaking URLs. There shouldn't be any performance impact as this detection will only happen on the first page hit.
> > Throughout the internals, I think we should use direct variable access
> > where we know we can. Generally functions are provided to retrieve
> > items, to discourage users from accessing the raw instance variable.
> > However, function calls are expensive, and there's no need for them when
> > we know that all the function does is return an instance variable. I
> > know you won't like this, but it's one of those practical things. And
> > yes, I realize it has the potential to cause us some pain if we change
> > the way a variable should be accessed, but it seems reasonable for the
> > speed increase.
> But what is the speed increase? Given the round trip network access and common disk and/or database access associated with a typical dynamic web page, I'm doubtful that eliminating a few function calls will speed things up.
I tested it by changing only the things in Application. It doesn't
speed things up <g>. BUt I'll tuck it away for use later if we're
looking for specks of speed.
> I think the sources of speed are:
> * Caching, caching, caching
> * Avoiding an interpretive scheme like DTML or WebObjects
> * Common optimizations like using hashes (e.g., dictionaries) instead of linear searches (e.g., x in list)
> As you alluded to, I see methods as an opportunity to change how things work, insert debugging statements, customize subclasses, etc. My ass has been saved many a time by using OOP.
> > On the issue of canBeReused and canBeThreaded, why don't we make these
> > class variables. Just set them once when the class is execed. THe
> Sounds good to me.
> Of course, I'd make them class methods, but Python doesn't have such a thing despite the Python FAQ's "half-denial" of that fact. :-)
> > reason I say this is then we can cache classes and still check that
> > value, without having to create an instance or call a function. Even
> > more heretical, I think we should provide both of these in the API, but
> > for now, I think a False on either of these should have the same effect,
> > cache the class and create a new instance for each request. As a quick
> If canBeThreaded=0 and canBeReused=1, why wouldn't I cache the object?
We might later on, but for now, we only cache one instance. If it can't
be threaded, then we have to create a new instance. If it can't be
reused, we create a new instance. This isn't a design decision, just a
current implementation decision. I'm thinking ahead to concurrency a
> > implementation, let's return a tuple from the factory creation
> > functions, the first item being the instance, the second a value of 1 or
> > 0, for cache the instance, don't cache the instance. Then cache the
> > class in the factory, as in the PSP factory.
> I'll have to think about this more before I have an opinion. I guess I'll have to think about it more before I make any changes you described just above it since this is an alternate way of doing things.
On second thought, scrap that. Let's just have
createServletForTransaction check the class variable that we agreed on
> What's the reason for caching the class in the factory?
Seems as good a place as any. It simplifies the logic in Application to
some extent. All Application has to worry about is instances and
whether or not to cache those (or pool them later). It knows that if it
doesn't have an instance, it goes to the factory to get it. How the
factory provides an instance is a factory decision.
> > More as I think of it, but I'd like your thoughts on these.
> Most of it looks good to me.