HCS Consulting Group.
We make Complex Systems simple

Why bother with .net when you have Thin Client?

By Albert D. Kallal
Monday, September 02, 2002

Why bother with .net? (Or Is the thick Client dead?)

The other day, someone pointed out a very nice link to a web based email program. This program was REAL nice, and functioned just like a email program that runs on your PC desktop. In other words, it was web based, but felt just like a nice windows program. (you know, a standard application with a menu bar across the top etc.). When you got some time, take a look at this link:


First, that is a *very* nice web interface. I have seen a couple of web based e-mail applications, and I would venture to say that it was purchased from that above company. Regardless, it is nice and users can instantly figure out how to use the application (this is due to their internal model and concept of a e-mail client).

This idea of purchasing a web e-mail client for local Internet providers brings up a very import point:

That local ISP now will NOT require itís users to work with, or rely on Outlook Express, or even Outlook. This could spell a change for software market. This means that most software today *should* have a thin client means of operation built in. (other wise, you will lose out to a competitor that does have this feature!).

As for creating a rich web interface, and not relying on the browser, I have one word to say:

D U H !!!

Just about everyone from Oracle to zooba zooba has figured out that one. They all now download a small client that *INTERPRETS* commands to a nice web interface, and do not rely on any type of html garbage interface. To be fair, that small client applet might crank out html for the browser, but I care less about that fact then if you are using a LCD monitor, or a CRT. This is not stuff the developer needs to worry about (again, we don't send html down the wire in this case..but a bunch of optimized drawing codes).

What the developer *does* need is a means to send the *output* of a application to a window. That window might be on the local pc, or a pc half way across the world. Hence, build the nice rich interface with your favorite best development environment, and then have it interpreted at the other end. Unix and X-windows (or tele-net for that matter) worked this way from day one.

Ok, now pop question:

Why did Microsoft not go this route when everyone else from Oracle to FileMaker, to Claris to the above OddPost.com has figured this one out? They all have dumped the idea of sending html down the wire, and now download a small client app that gives the user a rich windows like interface.

If you don't think Microsoft asked this question...then we are on the wrong planet. They HAD TO have asked this question! So, what was their response?

First, we all know that MS does have a thin client technology right now. So, I could be real blunt here and say why is everyone trying to write software that works over the web with a rich interface when we already have Windows Terminal Server from MS? Why is anyone even asking about thin client when it is already available from MS. Why even bother to re-write for the web when RDP is now shipped with every copy of windows? (RDP = Remote Desktop Protocol).

Chateau De Maintenon - France, Picture by Albert D. Kallal

Terminal Services for those of you who have not seen this AMAZING technology, is simply a means to run the windows interface across a network connection, and that includes the web. In other words, Microsoft already includes a protocol that allows a rich interface across a low bandwidth connection. Perhaps my only gripe with this technology is that is not based on a application window...but only the whole desktop window. The remote desktop support (RDP) in windows-xp is based on this..and it rocks! (it runs absolute circles around old concept stuff like pc-anywhere, or even the free open source VNC (I do use and like VNC).

I use TS a lot, and it is great. Why in the world I can NOT attach my applications output to a particular *window* socket is beyond me, but regardless, MS does have a fantastic thin client technology. I have a few clients using TS on a ms-access application between two cites. On both ends they use cheap high-speed net. Users in either city cannot tell the difference in speed and usability, despite the fact that the stuff runs from my City. I deployed this application to the web in less than 15 minutes.

Ok, so now we know that thin client has existed for MS. So now we know that you have zero reason to re-wire your software for the web, since again MS has thin client. You can deploy your windows application to the web tomorrow, and not have to re-write one line of code. I done this many times.

Since this ability is available to everyone, then why bother with .net?

The answer becomes obvious:

Imagine that when you turned on your computer it booted Directly to Excel. Excel is the *only* thing that it does. Problem is, that Excel AS A SINGLE STAND ALONE product has little value!

The fact that you can paste data from Excel into ms-word gives Excel value. The fact that you just filled a nice Excel spreadsheet from running a complex report in ms-access gives Excel value. The fact that you click on a button in your Decision Support system, and Excel is filled with some cool data from the corporate sql server gives Excel value.

It is this inter-operability that gives software its value. Hence, the fact that I can have a nice File-Open dialog pumped across the web is not a big deal (and as mentioned...just about vendor has this now anyway!). The real issue then is not thin client, but a means to extend inter-program communication between web based applications. This is where Microsoft is going, and thus explains why thin client was not adopted as a main strategy.

The problem with the above mentioned email client example is that is does not integrate into my OutLook contact list. Thus I now need to have two contact lists! The other problem is that the above example client can NOT be used by my software to send a email. I can easily do this with ms-outlook. If you every done any work for a company, and they ask:

"I need to press a button, and send this report to....."

This is also why Outlook is much better than Outlook Express. Outlook is a com object. This means that Outlook can be automated to do things with MY CODE. Outlook express is not a COM object, and thus can't be automated via my own code.

Thus, that web based email client is useful to check your email. Start developing applications for a company, and you will see that Email example is of ZERO use to them....*except* for Email. Just like the single minded pc that only runs Excel...it is of no use to anyone!

.net is simply program communication extended across the net (com objects can now talk to each other across the net). Hence, programs NEED to talk to each other. .Net thus gives my software an ability to talk to not only programs on MY desktop, but others across the web. It seems that a lot of competitors to Microsoft have not figured out this basic fact, and as a result Microsoft is going to win big time here.

I can't believe that most people don't get this basic concept. They all have now web enabled their software via some thin client. They pat themselves on the back, and say..hey we have web enabled our product. The problem is that they just enabled each of their products to work in a closed window in a web browser. Each program has ZERO awareness of each other program in those little "closed" browser windows.

This, Thin client gives no inter-programming communication. This is why Microsoft did not choose thin client.

Albert D. Kallal
Edmonton, Alberta Canada