Chuck Esterbrook wrote:
> Jay Love wrote:
> > > First of all, should I reconfigure the discussion list so that a [Reply] goes to the list instead of the sender? The admin page for GNU Mailman strongly recommended against that, but I don't know why. It seems like a pain in the ass to have to remember to hit [Reply All] and then remove the person's name so they don't get the msg twice.
> > >
> > > What do you think?
> > It is a pain. But There must be a reason they suggest it that way.
> Well, I'll take a closer look at their docs and then go from there.
> > > With regards to self._transaction, three things:
> > > * Do we kill the ability for a servlet to be multi-threaded if we record the transaction in an ivar? I believe the answer 'Yes', but please confirm. If so, do we really want to do that?
> > Yes, it kills the ability for an instance to be multithreaded. (Seems
> > to Me). However, I have noticed that instantiating an instance is
> > almost painless if the class is cached. Maybe we should switch to that
> > method. Might save some pain down the road. Please do some performance
> > tests for yourself and let me know what you think.
> I was already thinking that maybe the servlet factory can somehow let the app know if it really needs to keep going to the factory (I want this flexibility for future "plug-ins", experiments and so forth), or if it can just use the class.
> I think the API could be pretty simple: If the factory returns a class, the app just uses that. If it returns an object, then the app goes back to the factory next time around.
> Note that the app *always* goes to the factor for a path it hasn't served before. No big deal there, since incurring overhead on the first request is generally not a problem (since that's a rare case).
> > We're assigning it now in awake in Page.
> Right. I realized when I did that that Page lost it's multi-threaded ability. In retrospect, I'm wondering if I should have just stuck to passing the transaction as an argument and leaving it at that. Page developers can [a] assign locals to the objects that interest them and [b] create their own abstract subclass of Page called SitePage (or whatever) that does the kind of setup they want.
> > I don't know how much functinoality we're adding by reusing instances.
> > Do you see it as a functionality thing (might you store something in an
> > instance? I can't think of a good reason off the top of my head) or a
> > peformance thing?
> Solely a performance thing. Under the stress of a high volume site it may pay big dividends not to have to allocate (or keep a pool) of new objects for each request. I feel that if we forgo (sp?) that, we'll just end up adding it later.
Take a look at the performance thing. It really doesnt seem
noticeable. I'll do some tests too.
> > > * You say "It's needed above Page at least". Why is that?
> > Well, mainly because I just used it in Servlet for the Can
> > functionality. ;).
> I see. :-)
Otherwise, You'll have to pass the trans in to the getCan function,
making an already ugly function signature even longer and less object
> > > * Would we then remove the "transaction" parameter from respond() and sleep() for Servlets and if so, do we do that for other classes as well (right now all the signatures are the same).
> > You're the object man, you tell me. Is that poor design, or can we call
> > it a convenience parameter. I don't think extra parameters incur much
> > overhead.
> Oh, I don't mind the extra parameter in general, but I'd like the methods to match. For Servlet, I suppose you can have both self._transaction and the parameter trans, but that seems awfully weird.
> I'm leaning towards not assigning to ivars in Servlet.awake().
OK< but take a look at the performance thing first.
> BTW I'm interested in seeing your Can code just to see what's really going on there. When do you think you'll be able to shoot that over for a peek?
> Also, I'm taking a "break" by implementing "targets". So you can have 5 buttons in a form (like say, Add, Delete, Insert, Edit, ...) and have them hit the same Servlet, but different methods. I think it'll be pretty sweet. It was already on the TO DO list and the implementation has been bouncing around in my head for a week now.
> Webware-discuss mailing list