This page is the entrypoint for coordinating developer work.

New Release Goals

• Session affinity via proxying for multi-CPU/multi-server support -- something like perlbal in front of Continuity combined with Continuity issuing session id cookies. An example of that would be nice. Might be worth adding a minimal HTTP proxy to Continuity to do something similiar -- if a request comes in for a context that's on another CPU for vending machine, figure out (according to some formula the user provided) which IP/port to send it to and send it there (being careful to bail if they try to send it back to us).
• Cookies and CGI params as part of session key [done]
• Generic RequestHolder object and fixed API for Continuity::Request subclasses [done]
• Session cookies that refer to non-existant or invalid (failing some validation) should be treated as if the browser sent no cookie, and the server should send out a new cookie (right now it makes a new session but keeps the same session ID)
• Shouldn't die unless things are very seriously wrong -- that'll take out the whole app essays. Log it and sally forth. (This should be as simple as putting an eval { } around the main callback.)
• Perl.com Article
• Make it easy to get and set cookies, in addition to CGI::Cookie passthrough

Ongoing Pre 1.0 Work

• FastCGI interface (lags behind the HTTP::Daemon interface)
• Somewhat stable and well documented API -- important because subclasses set policy with regards to mapping requests to coroutines and such, and policy should be pluggable (documention improved)
• Fix up examples to match current API
• Test with the Illuminati server
• New logo

Development Todo

• More of a message passing backend -- at least examples of using Event to watch variables, creating queues, etc.
• DBI needs a wrapper package that knows how to use Coro::Event to wait for IO and give up the CPU in the interium -- same is true for lots of other packages, but DBI is the big one.
• send_static needs to use the io 'w' event too to avoid overflowing the buffer like C::Request::print does now.
• Make a "lite" mode where output blocks rather than switches contexts, so that it's safe to do print rather than $request->print. Investigate Coro::Select.
• Make a "stupid print hack" mode where print in the caller's package is redefined to a routine that searches the callstack using PadWalker to try to identify whichever request object is in scope and print to it. This should work even if the user only ever does $request->next. Or investigate Coro::Select.
• Decide whether people should simply be forced to do $request->print, if we should pick out the one to print to from the call stack, or if blocking when the output buffer is full and avoiding the need for it is the best plan for default, and how many options are really needed.
• Online debugger that knows about sessions (interactive inspector/debugger). Right now building a separate Continuity::Monitor.
• Use forks.pm as a backend optionally in place of Coro, or possibly in conjunction with it. This would make DBI work non-blockingly.
• Gopher Adapter.
• Userspace asyncronous component example

Done

• Remove built-in event loop, use Event/Coro::Event's instead (done)
• Read/write/accepts should all surrender CPU rather than block or lose (might possibly be working)
• Mapper should decide which requests are for static content to make that policy pluggable as well -- a good default would be to let users register a callback that returns true/false to indicate a request is for static content
• Pluggable Mapper
• HTTP::Request is used internally by both the mapper and the adapter, which makes the whole thing HTTP::Server-centric (but now Continuity::Request at least stands in for it and delegate to it)
• Server should configurably send "YouDieSoon" (calls a clean-up handler in the context of the targeted coroutine) and "YouDieNow" (terminates the coroutine) objects through the request queue to abandoned contexts after a specified amount of time

Biggest Bits of Conceptual Goo

This is a concept checklist of sorts for those who want to understand
the system in terms of its parts.

• Associating hits with coroutines (the Mapper)
• Creating Continuity::Request objects out of other "request" objects (the various Adapters)
• Cooperative multi-threading (Coro, Coro::Event, Event)
• The stupid $request->print() versus print() thing/associating output with the correct request object (manual right now, but lots in the todo about making it automatic)
• The request queue (queues, actually), where per-user continuations sleep waiting for a new Continuity::Request object to come in, and where the main server process sends Continuity::Requests objects to the appropriate per-user continuation's queue.
• Sending non-request objects and request objects alike through the request queues to get code to run in the context of another coroutine (eg, in process debugging/inspecting).

Random Jibberish

• Continuation Tracking Methods

right:Request_Flow.png

RSS Feed of Darcs Changes

health insurance quotes auto insurance quote red stag hunting otimização de sites desentupidora iluminação acompanhantes transportadora relogio de ponto dentista Florida Annuity Quotes insurance claims adjuster medical insurance custom poker chips duffel bags dating advice Doctor Lisa Alloju digital printing large format digital printing