start_response based handler can be used to implement streaming in Mojo, I guess.

AsCGI works but needs Server::CGI, an it's an indirection.

http://pythonpaste.org/modules/urlmap.html
http://rack.rubyforge.org/doc/classes/Rack/URLMap.html

define DSL to quickly enable Middleware in app.psgi

use Plack::Builder;

my $app = sub { .... };

builder {
enable MiddlewareX, @Args;
enable MiddlewareY, @Args;
} $app;

or something like that.

also to give an option of passing $self in the callback, maybe with an option or a different name like inline_object_with_self

http://search.cpan.org/~kevinj/AnyEvent-SCGI-1.0/
http://search.cpan.org/~orlandov/Catalyst-Engine-SCGI-0.02/
http://www.mems-exchange.org/software/scgi/

12:49 miyagawa: so yuval and I talked about how to optimize file serving in some backends
12:49 miyagawa: so even pure perl backends can use Sys::Sendfile etc. to serve static files
12:49 miyagawa: $body can be an array ref or filehandle-like object, so backend implementors can check fileno $body
12:50 miyagawa: and it returns the file descriptor it MAY optimize the file serving
12:50 miyagawa: looks good, but nginx and lighttpd needs a file path instead of a fd
12:50 miyagawa: Yappo can patch nginx to get fileno instead of path but:
12:50 miyagawa: one idea is to add a new type of $body which is a reference to file path
12:51 Yappo_: http://wiki.nginx.org/NginxEmbeddedPerlModule
12:51 miyagawa: like "/path/to/foo.jpg"
12:51 Yappo_: $r->sendfile is need filename
12:51 miyagawa: but then other backend implementors need to deal with this even if it doesn't support it
12:51 miyagawa: if it doesn't support sendfile()-like optimization
12:52 miyagawa: Rack can return a body that has to_path method
12:52 miyagawa: for this thing
12:53 miyagawa: maybe the app can set the path in $env
12:53 miyagawa: or $headers
12:54 miyagawa: i like the $env approach since middleware can edit this hash ref as well
12:54 miyagawa: really wish $fh can have ->path :)
12:56 miyagawa: so maybe impl can set $env->{'psgi.can_sendfile'} = TRUE
12:56 miyagawa: and app can set $env->{'psgi.sendfile_path'} = $path

http://code.google.com/p/perl-appengine/

Catalyst::Engine::Apache has some hack aronud $r->location and $r->unparsed_uri and shit

Now we can run Catalyst app as a PSGI app, so we can adopt tests from Catalyst and CGI::Application etc. to test a new Plack backend.

Write a psgi.async that uses start_response to do push streaming.

.

.

12:31 markstos: And this feels like a bug, but I'm not sure: If a run a simple CGI script on the command line, it prints the Content-Type header. If I run the same script through Plack and CGI::Emulate::PSGI, then it also prints 3 extra lines, which are usually supplied by the web server: "Status", "Date" and "Content-Length". Is it intentional that the Plack CGI Implementation prints these?
12:31 miyagawa: markstos: yeah i think so
12:32 miyagawa: because Emulate PSGI should be supposed to work as an app
12:32 miyagawa: Status, Date and Content-Length are something web server appends when run in CGI
12:32 markstos: You mean, an HTTP server?
12:32 miyagawa: well it's tricky but yes
12:32 miyagawa: Emulate::PSGI does something an HTTP server should do in the case of CGI
12:33 miyagawa: because it's not guaranteed the backend is really a CGI
12:33 miyagawa: well
12:33 miyagawa: there might have to be an argument whether app should set Status/Date or Impl should
12:33 miyagawa: i guess impl, but am not sure yet
12:33 markstos: Is it still OK to provide these headers if the environment is a CGI environment? I'll try to find the right docs to double check this.
12:33 miyagawa: i think it depends whethere it's running in nph mode or not
12:34 markstos: That sounds right.
12:34 miyagawa: but tokuhirom has a comment about which RFC/I-D says, doesn't he
12:34 miyagawa: yeah i think Impl should take care if it's running in nph or not
12:35 miyagawa: maybe Status shouldn't be set in the outgoing hearder, rather CGI::Emulate::PSGI should parse and turns it into the first arg of arrayref

patch is here:

• patch1: http://gist.github.com/198925
• patch2: http://gist.github.com/199421

patch2 is hack solution that use ioctl instead of fcntl.
we can't use way around whether F_SETFL is defined. this happen for runtime.

"Your vendor has not defined Fcntl macro F_SETFL, used at lib/Plack/Server/Standalone.pm line 53."

anyone?

Implement rackup-like PSGI app runner

add_header, remove_header etc.

Some backends do not set Content-Length when the app doesn't set it, which I think is problematic. Should clarify this in the spec and also add to Plack::Test suite.

Currently it DWIMs like

$res->body("Hello World");
$res->body($io_or_fh);
$res->body([ "Hello World" ]);
$res->body($obj_that_stringifies);

but is this a good thing? The whole if ref eq 'ARRAY' elsif ->can('getline') sounds a little uneasy. We might just want ->body_str($string) and pass through everything in ->body()?

request_uri looks up REQUEST_URI but it's not supposed to be always there.

_build_uri doesn't escape SCRIPT_NAME and PATH_INFO which might be URI decoded.

start_response thing

When you write a handler that opens a file handle and then run with AnyEvent backend to benchmark with apachebench, you'll see:

EV: error in callback (ignoring): Too many open files at face.psgi line 2.

I bet the file is not closed properly.

more better/readable implementation is required.

we can use HTTP::Request::AsCGI-like technique to wrap an existent CGI application to run under PSGI servers.

Update CGI.pm to support PSGI.

http://robhudson.github.com/django-debug-toolbar/
http://www.brynary.com/2009/4/22/rack-bug-debugging-toolbar-in-four-minutes

This would be a middleware to install debug toolbar panels and provide a basic fallback so app frameworks can record stuff, as well as a set of plugins to override common module methods like Memcached or DBI.

http://gist.github.com/187070

it refreshes the server process but $app code ref stays the same code reference, which means your application is not reloaded, which makes this reloader kind of useless.

request_uri is now back with $env->{REQUEST_URI} but i hate the name because

$req->uri gives the normalized absolute URI and $req->request_uri gives the raw URI from /. This is confusing.

We should have an unified way to indicate file path using X-Sendfile, or $env->{'psgix.sendfile'} or $body->name (using lsof.pm or such) so that:

1. Servers (Standalone etc.) should honor when they directly send file to clients with sendfile(2)
2. But frontend servers should strip X-Sendfile
3. And also can configure Standalone server so it can skip file serving and front lighttpd/nginx/Apache can do sendfile
4. What about reproxy (perlbal) though?

outgoing headers are taken care of mostly but i think Impl::* do not care really about multiple header lines with the same key.

We probably shouldn't use Path::Class here...

This is just because we don't support HTTP/1.1 in standalone. -0 option (force HTTP/1.0) would work.

and write an utility class to run various Impl.

This is a placeholder task to track IO::AIO patch for OSX.

there are some middleware components that you want to run in specific runtime conditions, such as based on IP address, cookies, User-Agent. It'd be nice if we can share those conditional rules rather than baking them in every single middleware. I think this could be a runner middleware that takes the original middleware and passes through i certain conditions.

I wonder if there are any similar attempts made in WSGI/Rack land.

this is a track to track whether Sys::Sendfile patch for OS X is applied and released on CPAN.

because of the delayed loading

http://gist.github.com/192083

like HTTP::Engine::Middleware::Static

.

1. with Standalone, when a file is updated it just exits the whole process
2. File::ChangeNotify depends on Moose : can we eliminate this?

response_cb doesn't implement poll_cb, and actually don't know how... it causes a deadlock easily

The current spec defined an application as a code reference. It would be nice if we can accept an object that ducks to ->call. It would require ALL implementors to add lines like:

$app = sub { $app->call } unless ref $app eq 'CODE';

before calling the app, or use autobox to let that happen magically. This might be a good compromise to allow PlackUp implementation and middleware developers so happy.

to deal with X-Forwarded-For

.

use overload thing is ugly.

use base qw(Plack::Middleware); sub call { ... }

and let Middleware.pm handle that thing. If we update PSGI spec to support ->call(), that overload thing should be gone.

18:08 miyagawa: 4745 at /home/comet/dev/Plack/lib/Plack/Server/Danga/Socket.pm line 209.
18:08 miyagawa: Use of uninitialized value in subroutine entry at /home/comet/dev/Plack/lib/Plack/Server/Danga/Socket.pm line 221.
18:08 miyagawa: : illegal fh argument, either not an OS file or read/write mode mismatch at /home/comet/dev/Plack/lib/Plack/Server/Danga/Socket.pm line 221.
18:09 miyagawa: んーこれ fileno わたさないとだめなんでしたっけ？
18:10 miyagawa: # Failed test at /home/comet/dev/Plack/lib/Plack/Test/Suite.pm line 157.
18:10 miyagawa: # got: '966656'
18:10 miyagawa: # expected: '2397701'

http://bulknews.typepad.com/blog/2009/09/path_info-decoding-horrors.html