First spec draft and FAQ is out
Tatsuhiko Miyagawa
I finished writing the first draft spec of PSGI on my 10 hour flight
from SFO to NRT. It's mostly a clone from Ruby's Rack with lots of
insightful observations from Python PEP333, but obviously changed a
couple of things so most Perl applications can easily implement. There
are things that need to be discussed / thought before making it a
final, so i dumped them in PSGI/FAQ.pod.
Specifications:
https://github.com/miyagawa/psgi-specs/
Feel free to comment on it via this mailing list or IRC channel
#http-engine at irc.perl.org.
But read the FAQ first, and come up with your real concern as a
developer, not just to criticize or nitpick.
Oh, and one thing that might need clarifications but not yet specified
is psgi.async support. We do have a working code in touhirom's psgiref
on psgi-spec-0.1 branch.
http://github.com/tokuhirom/p5-psgiref/commits/psgi-spec-0.1
Useful links:
PSGI Implementations:
http://github.com/miyagawa/Plack
http://github.com/tokuhirom/p5-psgiref
Web application adapters:
https://github.com/miyagawa/Catalyst-Engine-PSGI
https://github.com/miyagawa/CGI-Application-PSGI (not there yet, will
push later)
Original Announcement:
http://bulknews.typepad.com/blog/2009/09/psgi-perl-wsgi.html
--
Tatsuhiko Miyagawa
Mark Stosberg
First, thanks for your work on this. It's an exciting project. From
what I
understand of WSGI, it seems like a successful project worth
emulating.
Here's some feedback on the spec documents:
- Why does the application return an arrayref instead of an array?
Perhaps this is because some of the elements could be potentially
large, and
passing by reference may have benefits in performance or memory
consumption.
- Why are the variable names prefixed with "psgi". Would there
there be some possible interoperability possibilities if they used
the wsgi prefix instead?
- Should it be documented that a working can() method is required for
the
IO::Handle like objects? Maybe any object without a working can()
method should
be considered broken, so it goes without saying... I just remember a
time when
CGI.pm had a broken can() method due to a use of AUTOLOAD.
- One of my related frustations has been the various file upload
method APIs
out there. For example, CGI, CGI::Simple and Apache::Request all
handle this
slightly differently. Could you spell out how Plack helps with this?
I see that
that Plack provides Plack::Request::upload(), so perhaps the idea is
that frameworks
could re-use this rather than rolling their own.
- Also could you spell out how CGI.pm or CGI::Simple might fit into
all this? I
think I'm just too tired right now to see the obvious.
Mark
Tatsuhiko Miyagawa
On Wed, Sep 9, 2009 at 11:01 AM, Mark Stosberg<ma...@summersault.com> wrote:
> First, thanks for your work on this. It's an exciting project. From
> what I
> understand of WSGI, it seems like a successful project worth
> emulating.
Yes, it's a project to try emulating lots of efforts and proven
successful and useful there, instead of trying to be too smart and
saying "this is how Perl people should do" which sometimes could be
too smart.
> - Why does the application return an arrayref instead of an array?
>
> Perhaps this is because some of the elements could be potentially
> large, and
> passing by reference may have benefits in performance or memory
> consumption.
There's no reason other than Rack and JSGI does this (though JSGI does
an object). But I don't think it's worth changing to array either
since that's not an end user (application developer) should care.
>> - Why are the variable names prefixed with "psgi". Would there
> there be some possible interoperability possibilities if they used
> the wsgi prefix instead?
There won't be any issues if we change to something else as long as
all implementation uses. But why wsgi when a spec's name is PSGI
instead of wsgi. Nothing to gain from that. For the record, rack's
prefix is "rack." and jsgi is "jsgi.".
> - Should it be documented that a working can() method is required for
> the
> IO::Handle like objects? Maybe any object without a working can()
> method should
> be considered broken, so it goes without saying... I just remember a
> time when
> CGI.pm had a broken can() method due to a use of AUTOLOAD.
Yes we considered about this and the final spec is:
Servers SHOULD NOT check the type or class of the body but instead
just call C<getline> to iterate over the body and call C<close> when done.
This B<SHOULD NOT> means the server shouldn't call ->can('getline')
but instead just call ->getline(), because $fh->can('getline') FAILS
if it's a glob ref (even though you CAN call it )*sigh*). To answer o
your question, it's not required (but may be suggested) to implement
the completely working can().
> - One of my related frustations has been the various file upload
> method APIs out there. For example, CGI, CGI::Simple and Apache::Request all
> handle this slightly differently. Could you spell out how Plack helps with this?
> I see that that Plack provides Plack::Request::upload(), so perhaps the idea is
> that frameworks could re-use this rather than rolling their own.
Yes, upload() API is NOT what PSGI is trying to solve. Plack will
provide an utility method for it, but that's not required to be used
by either applications nor servers.
> - Also could you spell out how CGI.pm or CGI::Simple might fit into
> all this? I think I'm just too tired right now to see the obvious.
There are two things related to what we can do with CGI.pm or any
CGI-like objects:
a) Provide an utility to emulate CGI-executing environment, so the
existent CGI scripts whether it's written using CGI.pm or just a plain
<STDIN> and print STDOUT would work. This is already implemented by
tokuhirom as a Plack::Adapter::CGI but we agreed to make it a
standalone module, like CGI::PSGIfy, so othr PSGI server
implementations can use.
b) I'm planning to fork your CGI.pm repo on github to add a direct
support of PSGI. The only place where it should be changed is how it
prints and reads data from STDIN. CGI.pm already has a hook when
$MODPERL is set, so we can add another branch there to support PSGI,
which should be pretty straightforward.
Then all applications directly using CGI.pm can be changed so,
my $q = CGI->new($env);
to create a CGI.pm instance without fiddling with STDIN piping, and
frameworks like CGI::Application can provide a hook or subclass to
override where they instantiate CGI->new, in the case of cgiapp it's
cgiapp_get_query.
Then the framework like CGI::Application should also make a new method
or hook to return the output as PSGI-style array ref i.e. [ $code,
$headers, [ $body ] ]; instead of just printing STDOUT. Again, in the
case of cgiapp it's setting CGI_APP_RETURN_ONLY and return the array
ref using $output and $self->headers.
I actually plan to volunteer to write CGI::Application adapters when
YAPC::Asia, starting tonight, is over :)
--
Tatsuhiko Miyagawa
Mark Stosberg
Tatsuhiko,
Thanks for answering my questions.
> b) I'm planning to fork your CGI.pm repo on github to add a direct
> support of PSGI. The only place where it should be changed is how it
> prints and reads data from STDIN. CGI.pm already has a hook when
> $MODPERL is set, so we can add another branch there to support PSGI,
> which should be pretty straightforward.
Stein
will support these efforts as well.
> Then the framework like CGI::Application should also make a new method
> or hook to return the output as PSGI-style array ref i.e. [ $code,
> $headers, [ $body ] ]; instead of just printing STDOUT. Again, in the
> case of cgiapp it's setting CGI_APP_RETURN_ONLY and return the array
> ref using $output and $self->headers.
>
> I actually plan to volunteer to write CGI::Application adapters when
> YAPC::Asia, starting tonight, is over :)
Mark