threehv

I know, I know.

I’m slacking off on the RForward front.

Well I’m still flat out at work and the RForward deadline has been pushed back to the middle of June because of it.

If RForward 0.1 does not do it for you someone suggested this released under the MIT licence. As I was going to rewrite in .NET at some point anyway, I may use it as the basis for my 0.2 release. It doesn’t do the pseudo-load-balancing across multiple back end servers so you are stuck with ActionPack’s mutex – however for a low-volume site that looks as if it is IIS to the outside world it may well do the trick. I don’t know, I’ve not used it yet.

It’s a bit crappy and I didn’t really want to release it in this state, but I’m getting snowed under so I might as well let people take a look.

As you can read from the description, there’s a whole load of things that it does not do yet. I will be working on it soon enough, but I doubt I will get time before June. First on my list is to pass through the headers and the authentication – hopefully this week but I’m not really in a position to make any promises.

So, download and have a play. You’ll find that it probably falls short of your needs – but let me know where it needs updating (or if you have Delphi 7 update it yourself).

Enjoy and good luck!

B.

Although the Column View is best known for its appearance in NeXT’s File Browser (now called FTFFinder), it’s first appearance in a Jobs-derived product was in the Lisa.

However, credit has to go to Xerox as Smalltalk’s class browser has always had a set of columns for drilling through classes and methods (fixed columns as opposed to NeXT’s variable columns but …).

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.