Chris, Thanks for the interest. See below.
At 10:52 AM 11/2/2002 -0500, Chris Winters wrote: >Hi Stephen, > >I've finally been able to put some time toward the next version of >OpenInteract. One of my main goals is to enable OI to run under other >modes besides mod_perl, and to this end some of the things I'm doing >parallel what you've done in App::Context. > >However, yesterday I thought of the following problem: a Context >describes an application, but this is separate from the individual >requests coming in and the responses going out. It's fine to merge the >two (associate a request/response with a context) when you're working in >an old-school mod_perl environment, since each Apache child is only >handling one request/response at a time. I would say that a Context represents a runtime environment. It is possible that many applications are operated in this Context. >But what happens when you're working with threads? Or even in a >mock-threaded environment like POE? Since the context is presumably a >solar (I think that's the right word) singleton, you can't associate a >property of a thread (request/response) with it since other threads will >overwrite it or mistakenly pick it up. > >Have you thought about this? And, more importantly for me, how do you >intend to handle it? Doing a fairly quick reading through App::Context >on CPAN it looks like you did what I've done so far: > > my $ctx = OpenInteract::Context->instance; > my $request = $ctx->request; > my $response = $ctx->response; > ... >In servlets (Java or Perl libservlet), the request and response objects >are passed around to actions executing content. I'm not sure I see a way >around this.... 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. 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 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. 1. Have you thought about this? (multi-threading, mock-threading/POE) 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. 2. How do you intend to handle it? 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". 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. Furthermore, other critical services are provided for in the App-Context core distribution to allow for interprocess/interthread synchronization: App::ResourceLocker (formerly P5EEx::Blue::SharedResourceSet) App::SharedDatastore If more cleverness is required to properly handle multi-threaded Contexts, I will figure it out when I get there. Stephen
