[Catalyst] More detailed proposal for changes related to content negotiation and REST

John Napiorkowski jjn1056 at yahoo.com
Thu Aug 15 00:27:43 GMT 2013

> On Wednesday, August 14, 2013 6:15 AM, Will Crawford <billcrawford1970 at gmail.com> wrote:
> > On 14 August 2013 10:53, Will Crawford <billcrawford1970 at gmail.com> wrote:
> [...]
> Also, making it easier to restore a session id after deserialising a
> request. I was asked to implement an API that passes session IDs with
> an XML request body, rather than in the URL or a cookie. It turned out
> to be quite hard to restore the session, because even if I didn't
> write to the session at any point before that, anything that called
> ->sessionid (to see if there was one) caused this:
>     sub _load_sessionid {
>         my $c = shift;
>         return if $c->_tried_loading_session_id;
>         $c->_tried_loading_session_id(1);
> i.e. once you've checked for a session id, it won't try to load it
> later, even if you try to set a session id. We worked around this, at
> mst's suggestion, by creating a separate app and mounting it in
> myapp.psgi; would have preferred to just be able to call a
> "manually_set_this_session_id_and_restore_it" method, but couldn't 
> see
> one that was part of the public Session api.

Ultimately I'd like to refactor the Catalyst main request building flow to be layered using PSGI Middleware or similar (or at least that is my thinking now) and part of that would allow us to using middleware for some of th stuff we use plugins for (like authentication, etc).  I think over the long term the PLugin approach has not really scaled well and often we find its hard to fix things in Catalyst core because some popular plugins would break.  I think we could make this more robust, but that is probably not anytime so, although one step might be to try and refactor the catalyst dispatcher into psgi style middleware (make it easier to plugin in a new one, for example)


More information about the Catalyst mailing list