NAME
Plack::Middleware::Scrutiny - Scrutinize your [psgi] app with an [inline] debugger
SYNPOSIS
# This uses AnyEvent, so go with twiggy
builder {
enable 'Scrutiny';
$app;
};
# Now pass ?_scrutinize=1 to your app, and you'll get an inline debuggerDESCRIPTION
THIS IS A PROOF OF CONCEPT, MUCH WORK REMAINS!
Status: Kinda works!
This middleware adds an in-band debugger to your web application. When triggered (via a query string), your $app is executed in a forked context under the Devel::ebug debugger. Instead of getting your application output, you get a web-based debugger UI so you can step through your program's execution.
WHY
I was wondering why people don't use the perl debugger more. I did some very unscientific interviews and came up with the idea that it isn't that people are horribly opposed (though some are), but rather that it just isn't at their fingertips. Unlike Firebug, or even prints to STDERR, firing up the debugger is a bit of complication that doesn't seem worth the effort.
I'm hoping that putting enable 'Scrutiny' into your Plack::Builder setup will be worth the effort. Once this is working I'll probably look around for other ways to make this easy (like work on CGI::Inspect).
HOW
When this middleware is activated, right now by the _scrutinize=1 query param, it takes over the request. It forks into a parent and a child. The parent is what will talk to your browser for the debugging session, and the child is where your $app is actually executed. It opens a set of unix pipes to talk back and forth.
From there, the child uses Enbugger to load up Devel::ebug::Backend and gets ready to be debugged. Meanwhile the parent sets up Devel::ebug to talk to the child. I initially did this with Debug::Client, and that worked but I like the concept of Devel::ebug a bit better.
Finally, the parent outputs some HTML back to the browser with the actual UI. Future interactions from the browser are intercepted by the parent and considered commands to the debugger until the $app has completed its execution. Upon completion, the output from $app is finally sent to the browser instead of the debugger UI.
INTERNAL METHODS
This is documentation for maintainers, not for users.
$scrutiny->prepare_app
This gets called on middleware instantiation. All we need to do is get our static files set up.
$scrutiny->call($env)
Process a request. Here we split into two modes - either we are already in the debugger and need to display that UI, or we are working on a new request and need to get the parent/child setup going.
Also we might want to serve some static files for the debugger UI.
$scrutiny->new_request($env, $respond_cb)
This is a new request. After calling out to get the child started, we'll start watching for responses from the child.
BUGS
TONS I'm sure :)
This is still just a sketch.
One thing that I've found annoying is that 'step' doesn't actually seem to step over things. Along the same lines, this doesn't walk over the $app the way I expect/want.
TODO
There are a TON of ways this could be taken, especially since this is just a proof-of-concept so far. Some things are probably needed pretty soon, such as session based debugging (right now ALL new requests go to the debugger).
One significant thing that I'd like to do is to provide a more advanced separate window mode. In this mode you could explore code and set breakpoints (including on the path/query), and get a list of sessions that are currently awaiting your debugging. Selecting one would enter you into a debugging session. Handy for AJAXy stuff I think.
SEE ALSO
Code is on github: http://github.com/awwaiid/Scrutiny
Other fun stuff: Plack::Middleware, Plack::Middleware::Debug, Plack::Middleware::InteractiveDebugger, Devel::ebug
AUTHOR
Brock Wilcox <awwaiid@thelackthereof.org> - http://thelackthereof.org/COPYRIGHT
Copyright (c) 2011 Brock Wilcox <awwaiid@thelackthereof.org>. All rights
reserved. This program is free software; you can redistribute it and/or
modify it under the same terms as Perl itself.