Richard Bucker

RestMQ routing table for PerlMQ

Posted at — Dec 7, 2011

[Update 2011-12-11] After several months of preparation to build this app I’m regretfully abandoning the effort. a) the mojo guys; b) since I’ve decided to concentrate on Python… RestMQ will have to do because there is no sense in rewriting the code for TornadoWeb. Good luck to us all.As the project continues this article is going to convert the routing table from the RestMQ app to the PerlMQ version. The RestMQ snippet for the routing table associates the URL to a particular event handler in a list form. The Mojolicious version does not. In the Mojo version the URL and the handler’s signature are declared at once.Here is the RestMQ routing table:(r"/", IndexHandler),(r"/q/(.)", RestQueueHandler),(r"/c/(.)", CometQueueHandler),(r"/p/(.)", PolicyQueueHandler),(r"/j/(.)", JobQueueInfoHandler),(r"/stats/(.)", StatusHandler),(r"/queue", QueueHandler),(r"/control/(.)", QueueControlHandler),(r"/ws/(.)", WebSocketQueueHandler),Converting this to the perl version is going to be pretty easy. Most of the handlers have support for get/post and some support delete. These are the rest commands and the actual route or call of the individual function methods are handled by the frameworks. As to whether the list version is better than the inline version is to be debated.In my opinion the list version is better because it’s concise. The code is self documented right here. However, Mojolicious has an interesting feature is that it can export the routing table as part of the command line interface. This allows the user to verify the work before forcing the programmer to re-review the code from scratch.The Mojolicious analog of the route table above is as follows:# —————-> (r"/", IndexHandler),# http://localhost/?[queue=…]&[callback=…]get ‘/’ => sub { … }# http://localhost/# queue=# [msg=…]# [value=…]post ‘/’ => sub { … }# —————-> (r"/q/(.)", RestQueueHandler),# http://localhost/?[callback=…]get ‘/q’ => sub { … }# http://localhost/<queue>?[callback=…]# [msg=…]# [value=…]post ‘/q/:queue => sub { … }# http://localhost/<queue>?[callback=…]delete ‘/q/:queue’ => sub { … } # —————-> (r"/queue", QueueHandler),# http://localhost/queueget ‘/queue’ => sub { … }# http://localhost/queue# [msg=…]# [body=…]post ‘/queue’ => sub { … }# —————-> (r"/c/(.)", CometQueueHandler),get ‘/c/:queue’ => sub { … }# —————-> (r"/p/(.)", PolicyQueueHandler),# http://localhost/p/<queue>get ‘/p/:queue’ => sub { … }# http://localhost/p/<queue># [policy=…]# [callback=…]post ‘/p/:queue’ => sub { … }# —————-> (r"/j/(.)", JobQueueInfoHandler),# http://localhost/j/<queue>get ‘/j/:queue’ => sub { … }# —————-> (r"/stats/(.)", StatusHandler),# http://localhost/stats/<queue>get ‘/stats/:queue’ => sub { … }# —————-> (r"/control/(.)", QueueControlHandler),# http://localhost/control/[queue]get ‘/control/:queue’ => sub { … }# http://localhost/control/<queue># [status=(start|stop) ]post ‘/control/:queue’ => sub { … }# —————-> (r"/ws/(.)", WebSocketQueueHandler),# I’m not sure how this is going to translate yet#get '’ => sub { … }#post '' => sub { … }#delete '' => sub { … }PS: One thing that is missing from this project so far… is the actual layout of the folders and and sort of installation program. For the moment I have deferred that step because I’m still trying to decide whether or not to integrate this into the Mojo project (If they will take me).