RSS

Tag Archives: cyclone

“Mojolicious” has lost it’s Mojo

I’ve recently encountered my second issue with Mojolicious; since the Mojo team had recently added some core developers and reinstated their ticket system via GitHub I decided to open a ticket.

The first issue I presented to the team was their use of “daemon” as a command line param to launch your webapp, however, it unexpectedly ran the app in the foreground. My understanding of “daemon” and the behavior of any number of apps is that “-d” or daemon-mode meant background execution.

The issue I am currently working on is the new 2.37 version. It’s the first build from the new core team and that was a good thing, however, it would not build on my system (OpenBSD 5.0). So I reported it. The response that I received directed me to the CPAN team who verified that it worked.

Less obvious was the notion that I needed to check my dependencies. So I suggested exactly that… to which I received a reply that a) we were off topic and b) that there are no dependencies.

Well, ok… we were a little off topic… but there is such a thing as customer service. And while the cpan install file may not actually set the dependencies… they are listed on the CPAN page. So why not add that to the install?

So I’m up to my eyeballs in this. I’ve spent the last few months (calendar time) trying to wrap my head around this thing called Mojolicious. I happen to like perl and the CPAN. But I’m also frustrated with my two encounters with the Mojolicious team. They are neither smart enough or pretty enough to warrant this sort of snarkey-ness,

In the last 24-hours I’ve spent some time looking at flask, Werkzeug, Cyclone, and of course I already use Django and TornadoWeb. I also like python. The dependencies are easier here too.

 
1 Comment

Posted by on 2011/12/11 in web

 

Tags: , , , ,

RestMQ routing table for PerlMQ

[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/queue
get '/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).

 
Leave a comment

Posted by on 2011/12/07 in ProgLang, web

 

Tags: , , , , ,

Reverse Engineering RestMQ

RestMQ is no big secret. The source is available online and there is some doc too. The project I’m referring to was written in python using the Cyclone framework which depends on Twisted. I like both of those tools but they feel wrong for a project like this. It seems to me that the dependencies are too deep.

That’s when I requested and was granted an account from the CPAN team. My intention is to build a version of RestMQ in perl using the Mojolicious framework. I originally thought to call it ‘RestMQ-pl’ and then I thought of ‘PerlMQ’ and I’m also lingering on ‘MojoMQ’. The last one makes sense if I create a separate core API than can be integrated into the Mojo base code. (when I learn it)

The RestMQ code and doc is on par with just about every other open source project out there but there are some limits. One thing that is missing for me is enough code/doc that I can use as a requirements doc in order to implement the code in any language or any platform. So I am forced to install it and reverse engineer the behavior and the data.

The other item that I’m struggling with is that this article is getting longer and longer. It’s hard to edit, get feedback and move on to the next idea… and quite possibly abandon the article if there is no interest. So for the purpose of this article I’m going to address installing RestMQ, Cyclone and Twisted on an OpenBSD 5.0 system which I have been using for general purpose development for the last few months.

I tried to install RestMQ and it’s dependencies on an OpenBSD 5.0 system. My first attempt was a failure because the easy_install script reported that it was missing epoll.h which I’m pretty certain is a Linux kernel file and therefore is not going to be available on OpenBSD.

My next stop is the Twisted website to see if they have a proper build script. That too failed because while Twisted was available in source form there were still too many dependencies that I did not want to chase after… and while I really do want some “full stack awareness” at this moment it’s off target for the mission. Get ‘er installed.

I started my second attempt using an OpenBSD package:

# OpenBSD 5.0
pkg_add http://ftp.openbsd.org/pub/OpenBSD/5.0/packages/i386/py-twisted-web-11.0.0.tgz
easy_install cyclone
wget https://github.com/gleicon/restmq.git
cd restmq
python ./setup.py install

This was not going to be enough. A couple of the scripts expect the bash shell to be in a different place. There are a couple ways to solve this and for an OpenBSD system the following is a severe cheat. One should really correct the code. Possibly change the static to use “env”. But in the meantime that too would be off mission. So this sym link will have to do for the moment.

# need bash in the right place
ln -s /usr/local/bin/bash /bin/bash

Let’s see what happens next. From this point you should be able to follow the RestMQ instructions for starting and testing RestMQ… and it worked. Now for some reverse engineering.

(The next article will roughly address the route table.)
 
Leave a comment

Posted by on 2011/12/07 in web

 

Tags: , , , ,

All-time low for open source

Please follow my train of thought:

  • java is the now new COBOL
  • I used to like java when it was first released 1.02 was probably the best release albeit not speedy
  • There are so many libraries out there that overlap and intersect that it’s like looking at JCL through a kaleidoscope and I won’t even hint at J2EE
  • There are many alternatives that cover many different languages, python, perl, ruby, go, erlang, haskel, scala, clojure and so on
  • Some of them are clearly better than others… some are just plain stupid
  • I recently endeavored to design a system using python, TornadoWeb, Redis, and ZeroMQ. (simple, easy, fun and productive) The framework is about 3000 LOC and the dependencies are shallow and easy to expand. An alternative to TornadoWeb might be cyclone but it’s harder to build.
  • my next potential project needs to built in java including enough packages to be considered J2EE-light. Everything from Spring to Camel. There has to be a better way.
  • I thought to recommend SkyNet
  • It depends on doozer and go-lang
  • go-lang installs easy enough
  • doozer is crap, builds silently, but the test program does not compile.
  • doozerd is crappier, does not build because the libs to not match the go-libs. Why? fixed-em. I tried to run the test program and it crashed. Same errors.
  • roundup is worse still, there are even fewer docs here. I tried the normal build. FAIL. I tried the git version. Worked but there are no docs for me to test it. And now it’s installed… I hate that. Need a sandbox for the install much like go.
  • So I go back and look at the java packages.
  • they’re not so bad… if the project framework were templated.
  • Yes it is. More dependencies means more maintenance, more regression testing, more reading, harder debugging, more logging, slower transactions.
  • At the very least if I used Grails I’d have a chance to implement a smooth and normal install path. Not the chaos of package de jour.

Meh!  I’ll make it work anyway but it’s not going to be as much fun.

PS: What every happened to COBOL?

 

Tags: , , , , , , , , , , , ,

Current News and Updates

Google released version 1.5.1 of App Engine. They added some significant APIs and features, however, in my mind it’s missing a GO update.

Tornado has been in version 1.2.1 for a long time… and the developers just release version 2.0. (download here) Looking at the release notes there are 3 major updates and several minor. Many of the minor updates are prerequisites. The most impressive will undoubtedly be support for python 3.2. However there may be some minor backward compatibility issues.

 
Leave a comment

Posted by on 2011/06/22 in beta, ProgLang, updates

 

Tags: , , , ,

 
One Page Docs

Creating a library one page at a time.

One Page Bugs

Reducing the friction of writing and fixing bugs or features.

Follow

Get every new post delivered to your Inbox.

Join 223 other followers