Sparky is a lean, mean webserving machine I developed for Turbo10 and Trexy. I found configuring and performance tuning Apache + mod_perl so painful I ended up writing my own webserver!
Sparky is doing a great job of serving millions of hits per day for Turbo10 and Trexy. It's faster than mod_perl, consumes much less memory, has few prerequisites and is written in pure Perl. Last week I added POST request handling so Sparky now serves The Goo too.
The next phase in the development of Sparky is to fuse its currently separate Request and Response objects into a Context object (ala Catalyst). But I'm not sure how far I should go? Should I emulate the Catalyst dispatch mechanism too? Will this retrofit easily with Uwe Voelker's Catalyst port of The Goo?
I don't want to make yet another Catalyst (e.g., Jifty) but Sparky can't help but benefit from distilling the lessons learnt from these frameworks and others (CGI::Application, CGI::Prototype etc). Hmmm. No matter what happens I need to improve Sparky for Turbo10 and Trexy and a new Context object with a simple dispatch mechanism is definitely on the cards.
The Goo on the other hand will have its own application-specific dispatch mechanism no matter what underlying webserver is used. Given a 'Thing' in a URL (e.g., goo.cgi?thing=HelloWorld.pm&action=p), we need to look up its type (e.g., Perl 5 Thing), the action to be performed (e.g., p -> profile) and dispatch to the appropriate handler (e.g., Goo::Thing::pm::Perl5Profiler).
Each Goo user will also need to run a local "Goo Server" to access local files (i.e., a local file finder) and a light weight standalone server like Sparky is required here. Hmmm. Stay tuned ...
0 comments:
Post a Comment