Richard Vedyard posted an interesting collection of blogs on the subject of fat vs thin clients.
A key quote struck my eye from Phil Wainewright’s post:
“…what matters most is being able to tap into network resources…”
This is exactly the wrong way to look at things. We’ve been thinking about mobile devices as clients tied to servers, and this is backwards from reality. Mobile devices are computers in their own right, with their own resources. What matters most is the resources on the mobile device and being able to use them to best advantage. I’m sorry, but the thin client paradigm falls down on this every time.
A big debate is brewing in the mobile software space over the best type of client – thin or rich?
Like many high tech terms, the words used are vetted by spinmeisters who don’t like the term “thick” or the opposite of “rich” (thus my title).
I suppose it’s no surprise that Microsoft’s .NET Compact Framework features a lot of support for rich clients.
On the other hand, the Alchemy project Adam Bosworth started at BEA (before he left for Google last week) is based on a thin client architecture.
Who’s right typically depends on what you’re using the application for, of course. In some cases, a thin client will be a better natural fit than a thick client and vice versa.
However, for mobile applications, and especially for the new type of user we’re building them for, rich clients make a lot more sense than thin clients.
I want to thank Steve Vinoski for pointing me in the direction of some good new music. After a few tries (including a visit to the Apple Store in San Francisco) I finally managed to find a blue iPod Mini.
Actually I ran into a former Digital colleague of mine at the Apple Store in Nashua, NH and he agreed to call me when one came in. They did, and I had 24 hours to go retrieve it, after giving my credit card number to hold it. I guess the problem is obtaining enough of the 4 GIG mini hard drives.
Anyway, I did get the iPod in time for my trip to California last week. Combined with the Bose noise cancelling headphones, it really helps pass the time on the plane. It is really cool, I can see why everyone wants one. I love it.
Steve’s recommendation of the Allman Brothers sent me to the CD store, where I picked up Hittin the Note and a deluxe edition of Live at the Fillmore East which I just could not resist. I think that’s like my third or fourth copy of that album.
I saw the Allman Brothers for the first time in the spring of 1971 at Quinnipiac College (I just checked their Web site and couldn’t find any record of their having played at Quinnipiac – help me out guys, am I losing my meory?). I remember a band called Jasper opening for them. It was definitely one of the best concerts I have ever seen.
I saw them again about a year later, in April 1972 in New Haven (that one is on the Web site). Berry Oakley was still alive then, but it was a different band without Duane. The back and forth between Duane and Dickie Betts was the best part of the show, each of them trying to outdo the other. You can really hear it on the Fillmore East album.
I notice on Hittin the Note that Warren Haynes takes the left side of the stereo, and Derek Trucks takes the right side. In the original line up it was Duane on the left and Dickie on the right. Warren and Derek are tremendous, as Steve rightly points out, and they manage to play with the same kind of spirit as the original lineup, without sounding like they’re imitiating them. But I can’t help going back to the original jams on You Don’t Love Me, Whipping Post, and Mountain Jam – unbelievable.
Anyway, speaking of the Allman Brothers, I notice that Los Lonely Boys are opening for them when they play in Massachussets next month. I picked up their CD, and it’s great. Henry Garza reminds me of Duane sometimes, of Carlos Santana sometimes, and even of Stevie Ray sometimes. They do ballads and rockers. Excellent!
My 18-year old son didn’t like Los Lonely Boys, although my 19-year old daughter did. But he and I did agree on Velvet Revolver, another of Steve’s picks. Great stuff, solid, consistent songs throughout the CD. But I have a complaint about that CD, which is the “LaunchCD” software that comes on the disk. It installs some programs on my computer that I didn’t want (after I found out what they did, basically making it difficult to rip and copy the files) and I could not find a good way to uninstall them. I had to go search for the DLLs and rename them.
It’s one thing to protect the disc contents with licenses, but it’s another to hijack my computer. The programs not only prevent copying the songs, they also wreck any recordable CD you put in the burner when you try it. I know blank CDs aren’t expensive, but I still think it’s bad form to wreck them. I had to go find the files by hand and remove them – they should at least allow you to uninstall if you don’t want it.
Last week while talking with Frank Martinez during the BEA show (and this is really one of the great things about my job, that I get a chance to meet and talk with interesting people like Frank), I started on a version of my mini-rant about SQL and GUIs being labor-draining anachronisms. Frank basically agreed, and that’s about all the encouragement I need to try to write it all down here ;-).
The point is that it just takes too much time and effort to design, develop, and adminster a database and associated GUI. Who can really afford to take on all the data modeling, normalization, and structuring work necessary to define a sensible database and usable GUI?
The benefits seem very small given the huge amount of effort. After all, most database applications just extract the variable data items from the static fields, figure out how to store them in the database, and then retrieve them so they can “rehydrate” them back into the GUIs from which they were extracted.
This all started when storage space was tight in the early days of business computing, when every byte counted and we (all) did things like store “82” instead of “1982” and measured program load sectors in 16K chunks (for example). Processing power was non-existent on the desktop, and even the servers were constrained. Data and its presentation needed to be managed carefully to maximize hardware and software capacity.
Today storage space is essentially free, and there’s an abundance of cheap and available processing power from the desktop to the mid tier to the back end. Why not just store the data along with its formatting information in an XML file and just render it when it needs to be displayed or interacted with? Just store everything — variable and static — in the XML documents and XML Forms and eliminate all that unnecessary database and GUI design and development labor.
Of course, SQL is really no more dead than CORBA, Java, or the mainframe — at least not yet.
But there is no longer any good reason to assume that structured data is the right solution for every data management problem. A large number of applications manipulate data intended for use by one person at a time. A database and GUI application is really overkill for that.
On the other hand, applications like airline reservations and buying concert tickets will probably always need structured data, since they rely upon the ability to accurately manage shared access to a single data item instance (i.e. the airplane or concert hall seat) so that it is sold only once and on a first come first served basis.
Applications like purchase order approval, medical records distribution, expense report filing, engineering and repair drawing distribution, safety inspections, and so on, really do not derive any benefit from the significant effort required to structure their data.
These are also the applications that are increasingly important to “mobilize,” and structured data is not the right approach, not just because of the excessive labor involved, but also because the database replication and synchronization problem is basically unsolvable over a WAN.
This isn’t to say that structured data isn’t important, but it is more important for field workers to have the ability to orchestrate the distribution of unstructured, personal content to the right individual at the right time, and SQL just can’t do the job.