[Catalyst] Web Services Integration with Catalyst

[Matt S Trout]

On Sun, Oct 14, 2007 at 05:27:58PM -0700, Bill Moseley wrote:
> On Sun, Oct 14, 2007 at 08:38:52PM +0100, Matt S Trout wrote:
> > 
> > Catalyst::Plugin::Server is what was going to be the community-designed new
> > Plugin::XMLRPC until the namespace owner decided he didn't like the API,
> > revoked the PAUSE bits for the ::Server authors and released his own
> > one-day-hack rewrite with no reference to any of the design work done. So
> > we picked a new namespace and went ahead with ::Server anyway.
> 
> Not sure I followed all of that.  I was confused about which namespace
> you were referring to, but I see you responded about that in another
> thread.
> 
> 
> I have a more general Catalyst question about Catalyst::Plugin::Server's
> design.
> 
> Catalyst::Plugin::Server::XMLRPC uses prepare_action to both parse
> the XML *and* to call prepare_action to find the action for the
> request.
> 
> Shouldn't the parsing happen earlier in the request (prepare_body)?
> 
> Why do I ask?
> 
> I'm toying with using a ticket based authentication where the token
> would be sent in the XMLRPC request body, but use the existing
> (cookie-based) session setup that that application uses.
> 
> One way to do this might be to return that token in get_session_id():
> 
>     sub get_session_id {
>         my $c = shift;
> 
>         return $c->stash->{xmlrpc_token} || $c->NEXT::get_session_id;
>     }
> 
> Of course, the parsing of the body would need to happen before the
> session is accessed.  But, C::P::Session also has a prepare_action
> that might access the session id  So, it's possible that
> get_session_id might get called before parsing of the XMLRPC body.
> I guess careful ordering of the plugins could resolve that, but would
> you agree that the parsing should happen earlier than prepare_action?

I think ideally we should extend C::Request and HTTP::Body so it can be
parsed as "just another request body type".

Either way, parsing at prepare_body time does seem to make sense to me.
 
> BTW -- when looking over the module I noticed that it adds a number of
> "attributes" into all the actions.
> 
> I'm not that familiar with the internals here, but I was curious why
> "XMLRPCRegexp" would be added to "Catalyst::DispatchType::Path".
> 
> Is that expected?
> 
> 
> bless( {
> 
>     'namespace' => 'user',
>     'name' => 'list',
>     'class' => 'MyApp::Controller::User',
>     'attributes' => {
>                       'XMLRPCRegexp' => undef,
>                       'XMLRPCLocalRegexp' => undef,
>                       'Path' => [
>                                   'user/list'
>                                 ],
>                       'XMLRPCLocalRegex' => undef,
>                       'XMLRPCRegex' => undef
>                     },
>     'code' => sub { "DUMMY" },
>     'reverse' => 'user/list'
>   }, 'Catalyst::Action' )
> 'Catalyst::DispatchType::Path']

I suspect that's auto-vivifaction from the XMLRPC dispatch types somehow,
which does seem a bit odd.

I'm fairly sure it's harmless, but a patch and test would be appreciated
nonetheless.

-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director                    http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/            http://www.shadowcat.co.uk/servers/