Request! What kind of Request?

So, Plack::Request is probably the most useful class/utility in the Plack/PSGI ecosystem but at the same time confuses people to think that Plack is more of a framework or a library for end users rather than for an application framework developer.

xSGI/Rack Request classes

Rack has Rack::Request which is a base class for Sinatra::Request and also is used in many Rack middleware components. WSGI doesn't have one unified implementation, so most middleware components are implemented in each framework, but there is also WebOb.py that is a parser for WSGI requests and provides Request objects.

Plack::Request is supposed to fit this layer as it's clearly documented in its POD. But it misses some functionalities like a) not being able to write new attributes through an accessor and b) there's no way to rewind psgi.input for later read. They are bugs, and should be fixed, but it's important to note that Request objects on this layer should be generic enough so it can work with any upstream frameworks, and it'd be nice if it can be subclassed in a new framework that doesn't have their own Request objects, such as Tatsumaki.

Framework Request classes

Most frameworks have their own Request classes: django, Rails, Merb, Sinatra, HTTP::Engine, and Catalyst. They can define their own methods and have nothing to do with xSGI Request classes but when you develop a new Perl web framework with PSGI/Plack then it's nice to have Plack::Request as a base class to add methods to it.

So what?

Currently, the name Plack::Request, and the fact that you can use it directly to write PSGI apps "suggests" that it is the way to write Plack apps. Actually, I see some examples and blog posts explaining "How to convert your Catalyst applications to Plack" using Plack::Request, which totally doesn't make sense.

Also, if a new framework uses Plack::Request and inherits from it, end users, sometimes as well as authors think that the framework depends on Plack (as a server) and can't run it on other PSGI server implementations such as mod_psgi, which is totally not true.

Plack and PSGI avoided having one implementation and interface (like Rack) and separated the interface and implementations like Python WSGI does. Considering that, does it make more sense to have different names for a) Request libraries to write Plack middleware and b) Request object you can extend in frameworks?

If so, I'd merge Plack::Request back to Plack core dist, strip some misused features such as param (!), and provide another Request class (that probably uses Plack::Request inside) and is fully extensible. We'll see...

Comments

[Jakub Narebski]

If it is meant to be generic, why not PSGI::Request?

[miyagawa]

No, PSGI is an interface and there should not be PSGI::* modules that implements PSGI because that'd confuse more people.
http://search.cpan.org/~miyagawa/PSGI-1.03/PSGI/FAQ.pod#What_namespaces_should_I_use_to_implement_PSGI_support?

[Patrick Donelan]

This is the question I'm mulling over for the "proper" WebGUI plackification (PlebGUI was just a proof of concept). WebGUI is its own framework (it doesn't use a framework like Catalyst), so it's a perfect example of where you start wondering if you should subclass Plack::Request. Suggestions most welcome!!