On Mon, 2002-11-04 at 15:08, Stephen Adkins wrote: > I would say that a Context represents a runtime environment. > It is possible that many applications are operated in this Context.
This is a useful distinction. > 0. General > > So far, I have a need for only two Contexts: > > App::Context::HTTP CGI or mod_perl Registry processing > App::Context::Modperl within a mod_perl handler > > and I probably will want to add > > App::Context::HTTPDaemon > > A Request named App::Request::CGI will handle serve as the default > Request class for App::Context::HTTP, and App::Request::ApacheRequest > (or something) will serve as the default Request class for > App:Context::Modperl. Right, I have something similar so far. > My Request objects are (envisioned to be) higher level than the > Java Servlets request classes. They represent/contain the > > * session state > * a set of changes to the session state > * a set of events (with arguments) to execute in the session I assume that 'session state' includes the client environment (IP, user agent, etc.)? > So far, I really have not had a need to differentiate between implementations > of the Response class. The Response class may go away completely. > Right now, it is the Context that decides how content requested in > the Request is sent back to the client. Ah, I think your Context is doing more than I'd envisioned... > Yes, I have thought about it. > I haven't coded much for it yet because I don't need it yet. > I expect to add other implementations of the Context class to handle > the details of managing the variety of Requests currently being processed > within a Context. I don't need it yet either. I generally don't try to predict the future by trying to account for all possibilities, but this seems like an area where I could shoot myself in the foot without giving it at least a litle forethought. > The important thing here is that each Request knows nothing about any > other Request currently being processed. Therefore, from a programming > point of view, when some code refers to $context->request(), it is > getting the "active request". I agree entirely with the first part. The second part, I'm not so sure about... (next para) > The Context, in complex runtime environments, is like a multi-tasking > CPU scheduler. > > A multi-tasking CPU scheduler is responsible to store all of > the CPU registers for a task being preempted and to restore all of the > CPU registers for a task being scheduled. This is called a context > switch. Each program refers to its registers, program counter, > stack pointer, etc. just as if it were the only program in the world. > > I envision it to be the same with the Context implementation in complex > runtime environments. Yes, your Context is definitely doing more. I had seen the Context as a read-mostly environment that has configuration information about one or more applications along with access to configured services -- caching, datastores, debugging/logging, object lookups, etc. Along with this, I figured that whatever runtime environment the application was running in (mod_perl, POE, etc.) would deal with the sort of context switching you described above. That seems like a difficult problem to me, one I'm much too lazy to deal with :-) Well, I guess we'll see how they work! Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
