The blog of Rahoul Baruah from 3hv Ltd

What's going on?

My name is Rahoul Baruah (aka Baz) and I'm a software developer in Leeds (England).

This is a log of things I've discovered while writing software in Ruby on Rails. In other words, geek stuff.

However, I've decided to put this blog on ice - I would ask you to check out my business blog here (or subscribe here).

02 May, 2006

RForwards Update No. 1

A quick update.

Progress is slow. Customers keep getting in the way - weeks without a bug reported and then loads come in at once. Typical eh?

However, I have had some feedback and the next release should address at least some of these:

  • HTTP Headers are currently not passed from IIS to the back-end server
  • Unicode characters are currently mangled
  • The auth_user and remote_user environment variables need to be passed through to the back-end server as pseudo-HTTP-header values to allow integrated Windows authentication
  • RForwards does not currently deal with multiple applications installed into a single web-site
  • Currently RForwards stores its state in the registry. Not only is this incompatible with the "multiple applications/single web-site" scenario above but it is likely to slow performance. Instead I am going to rely on IIS loading the DLL once and critical section a global variable for the state.
  • Likewise, RForwards configuration is stored in the registry. Again, incompatible with multiple applications. Instead I am going to use a local INI file that is read on DLL-load.
And lastly, a quick clarification. RForwards is nothing to do with FastCGI. As far as I can see, FastCGI, while it works for some, is difficult to install, configure and trouble-shoot. Whereas it is easy to get your application running on WEBrick and equally easy to install an ISAPI DLL into IIS. RForwards is supposed to take advantage of that simplicity and replace the house of cards that is my FastCGI instructions.

Why bother? Lots of "corporate" clients want to have IIS as their web-front end and won't trust a poxy Ruby server (plus WEBrick only handles a single request at a time as ActionPack has a great big, fat mutex on entry). So RForwards makes it appear as if IIS is serving the requests while actually acting as a load balancer to many WEBrick processes. In this way, the pointy-hairs are kept happy ("oh yes, we use IIS to serve our Web 2.0 Rails AJAX tag-soup application just like Scoble suggested") and the mutex isn't overloaded as each WEBrick process in turn gets the chance to handle a request.

My personal deadline for this work is the end of May. So, as long as I can clear these bugs off my desk (and finish some other development also due at the same time) we should have a new, beta quality release by June.

3 comments:

Tim Morgan said...

I'd like to voice my support for this project. This is exactly what I need! I'd even be willing to throw a few bucks your way if you have a pay pal account or some other way to donate to this project. Have you posted the current code anywhere yet?

Baz said...

I'm not ready to release it to anyone and everyone (should be in a couple of weeks) - but mail me (same as my MSN on my profile) and I'll let you have an early copy.

Baz said...

As for cash - this work is currently funded by my employer. I have their permission and everything - even though I'm not sure they 100% understand what I am doing (especially the LGPL part).

But soon enough it will do enough to keep them happy and any further development will take place in my spare time - if and when that happens I will happily accept your donations!

eXTReMe Tracker