New Information Thin Client Limitation

You are building a typical CRUD user interface: For which tasks should you get involved in with the server ? I believe that there is no good reason for object/data creation to involve server communication. I believe server communication is fine for the URD in CRUD, but, why involve the server on creation if you still haven't clicked on the "save" button? If at the end you decide to click "Cancel" you have wasted time and resources talking to the server about something that was not going to be persisted. This reduces scalability and on slow networks creates a perception of bad performance that it is hard to justify with the end user.

When building a FatClient, involving the server is an option, when building a ThinClient is an obligation, it doesn't matter if you require it, you are forced to communicate with the server for everything.

On first sight, it is not easy to see the difference between building an application based in the NewThinClientParadigm? (also known as HTML) and using something with full ClientServer support, after all, if you add JavaScript to the mix HTML/Javascript becomes a typical ClientServer solution (with no real difference when compared with BorlandDelphi, JavaSwing or WindowsForms). {A.K.A. HtmlDomJsCss}

So the path is there, and has been walked before, define all (or most) of you information with your Client side language, and user the server side only to answer queries to the database or run batch processes.

Well, people resist to that... and in this resistance they build stuff like RichFaces?, IceFaces?, AspNetAjaxExtensions?, etc, because they want to be able to define their UI on the server, bound to server side controllers, that are safe inside the server, and can't be tampered by malicious clients. And they build great stuff (the latest and greatest could be AribaWeb). But as all abstractions, this one leaks... horribly.

It seems like an easy problem to solve: update your UI as a result of user interactions: The user does something, you transmit this something to the controller, he reacts, and some part of you UI get refreshed... so far, so good.... you are reading information stored in the server so you have to go to the server to get it...

But then you have to create a new object, this is the leak in of your abstraction:

You create a new object, and since it is new, the most efficient thing is for it to exist only on the client (if you were coding with full ClientServer support, thats what you would do, wouldn't you?), but you can not represent that in your server based technology... what to do? well, you say, lets just create it by default when you load the "Edit" page after clicking the new button, after all, you need to do a redirect, so you still have to go to the server to fetch the UI... and you go on....

But then you realize that you have to have a one to many relationship going from you new object to children objects, so you add a button "New Child", while you are coding it you realize that you are going to have to violate your server side principles again, this time with no redirect to justify it, because the UI to capture your new child will be in a floating ModalPanel?.

Now this new child object is going to have to be linked to the parent object, and... where should you do that? You can of course, go to the server again to do it but.... what is the justification? You do not need any old information to create the new object (it is after all new), but, you do need to link it to the parent object... How to justify the performance penalty of going to the server just to link all new objects? Specially if after all you might just hit cancel in the "edit" page of your root new object, and send every new object to oblivion?

And so the ThinClientHasFailed

Can anyone understand what this page is trying to communicate? I'm completely lost.

Me too, though it's curious to watch how each successive paragraph is is less meaningful than the paragraph preceding it in an almost linear fashion. I think it desperately needs more explanation, clarity, and perhaps some examples -- especially toward the end.

After re-reading it again, I think the thesis of this ramble is that the thin client has failed because object/data creation can only occur on the client, and not involve server communications. The problem is not that object/data creation can only occur on the client, and not involve server communications, the problem is that object/data creation most occur only on the client, and not involve server communications: Why involve the server, if you haven't clicked on the "save" button? Why waste time and network resources with something that you may end up canceling anyway?

This is, of course, patently false, as anyone who's ever used GMail can attest to personally (drafts are saved to the server periodically and completely transparently to the user, so you don't lose too much data even if your network connection goes down). There even is an AJAX-y implementation of ColorForth called RainbowForth (http://rainbowforth.sourceforge.net/) which works similarly. Thus, there is no NewInformationThinClientLimitation.

So you mean GoogleWebToolkit based GMail is you example of a ThinClient? AFAIK GoogleWebToolkit compiles Java in to JavaScript that runs on the client... what is the real difference between that and downloading Thunderbird? (Think it like this, if Thunderbird were written in Javascript, and you could run it with AdobeAir? would that be Thin or a FatClient ?

I believe I wrote that the thesis of the article was, "that the thin client has failed because object/data creation can only occur on the client, and not involve server communications." My argument has nothing to do with whether GMail is or is not a thin client. What I did use GMail as an illustration for is a client-side program which routinely employed server-side communications as a necessary component of its data creation capability. By way of (rather obvious to me) extension, any client-side program, thin, fat, clinically obese, whatever, can employ a similar strategy, thus utterly disproving what I thought the original poster's thesis was.

If your argument had nothing to do with whether GMail is or is not a thin client, then why mention GMail at all? why you didn't use ThunderBird? or OutLook? for your argument?

At risk of sounding very offensive, I really wish people would learn comprehension. It really would cut down on the noise and unnecessary confrontation on this wiki, to say nothing of my blood pressure. I apologize if I'm coming off unusually upset. It just really irks me when people respond to what I've written, particularly in a manner I interpret as singularly snooty, without fully understanding the entirety of the context.

Comprehension is a two-way street -- it depends on the receptiveness & understanding of the reader and the clarity of the writer. No offence intended, but... In the above, the latter was somewhat lacking, especially toward the end.

Now, on to why you'd want to involve the server -- simple. Data loss through network connectivity issues. If I'm typing something up on GMail, and suddenly my power goes out, that's OK -- I have a recent snapshot of my composition tucked away in GMail's Drafts folder. If this happens anywhere that doesn't involve a client/server interaction, I'd be right pissed, to the point where I WILL NEVER USE THAT SERVICE EVER, EVER, EVER AGAIN, INCLUDING IF PAID.

This becomes increasingly important the thinner the client. Remember, the Internet is predicated on a dumb infrastructure, and smart end-points. GMail is one end-point. My computer is the other. Either we both have equally smart applications interoperating, or GMail has the smarter, or mine has the smarter. In other words, the sum total of smarts between GMail and my system must be a constant. Since scripts running in web browsers have zero access to the filesystem beyond simple cookies (particularly if I disable it, which I would if given the option), it follows taht GMail must be the endpoint with the persistence. Thus, I fully expect GMail to cache my work-in-progress in the event of a communications failure.

Note the word there: expect. This isn't a nicety. It isn't even optional. It is a requirement.

[I'm going to second that. The original author appears to be saying that creating objects somehow violates the ThinClient assumptions. That is just plain false. There is no reason for object creation to be conceptually different than any other object manipulation. One could do something similar to what GMail appears to do and create a default object and then manipulate that object into the desired state. One could also (just as is done with regular object manipulations) provide a form to fill out that gathers the data required to create the object, and create the object when the form is submitted. Which one is better depends on the situation. Neither approach makes it any less ThinClient.]

[Nesting object creation changes nothing conceptually either. One can either include the data needed to create the children in with the data needed to create the parent, or create a default and manipulate, or allow the child to be created without the parent, and when the parent is created link the children to it. None of those options violate ThinClient either.]

[I will also second that if object creation is complex and needs to be picked up from multiple locations, the GMail approach is most likely the way to go.]

This brings something interesting to mind: maybe the definition of a ThinClient isn't that which cannot run TuringComplete code. Instead, maybe a ThinClient is simply any client which lacks its own means of persistence.

That's an interesting thought. Perhaps "thin-ness" can be graded on a scale, with lack of TC and persistence being 2 factors involved in the rank. Let's see what contributes to "thin-ness":

EditHint: New topic ThinClientDefinition? ?

{Gradually moving definition list to ThinClient, since it is not a large topic at this time.}

Guys, I'm not sure who is involved in the discussion here, or what text you're talking about, but *I* am the one who asked how my rebuttal to the original post could have been made more clear, such that someone who asked me if I thought GMail was an example of a ThinClient or other future authors would not misunderstand me in the future. I regret to say that my question still stands unanswered, even if the response given has helped others. --Samuel A. Falvo II

Mmmmm, so you you'd want to involve the server to prevent data loss through network connectivity issues.... So you actually believe its is better to send you local changes all the way thought the network instead of just saving them locally? I mean, if you concern is network failure, use a big FatClient, but that of course also proves that the ThinClientHasFailed

Well, I fully expect you to download ThunderBird? and save to your local hard disk if losing your work in progress is such a big concern. OTOH I can see the convenience of GMail behavior, but since GMail is not a ThinClient, we shouldn't even be discussing it here

Of course GMail isn't a thin client -- GMail is the application. My browser is what serves as the thin client. Make sure you keep your concepts straight.

Oh that is just great, you browser weights what? 7.1 Mbytes? So... Any runtime under 7.1 Megabytes is automatically a "ThinClient"? and what about applications built using WinThirtyTwo api directly? Those use an NullClient?? And if I were to write a web browser using JavaScript as the implementation language... what would that be? (other than an exercise on self torture). Oh, and thanks for writing "of course GMail isn't a thin client " now that renders GMail irrelevant for this discussion, in fact I don't care what kind of client is GMail, as long as you admit that is not a ThinClient

As far as expectations are concerned, well, I hate to be the one to ruin your worldview. No fat client is ever, ever, as usable as the GMail interface, for the simple reason that the numerous deployments do not talk to each other.

I also wouldn't want to be the one to ruin your worldview, but GMail is not a PeerToPeer solution, it has not "talk to each other" capability, it is plain old centralized to Google servers software, as limited as any other FatClient, in fact, more limited, true FatClients? can talk to each other using PeerToPeer technology, that as of now, is not available for HtmlDomJsCss based applications

First of all, Thunderbird is a piece of shit in and of itself. I'd rather use Outlook over it anyday, and as a die-hard anti-Microsoft proponent, that's saying a lot. Second, as a person who uses the e-mail interface from numerous consoles (laptop, desktop, sometimes even cell phone), having a consistent, coherent interface across all consoles proves extremely valuable. No, I'm not going to carry a laptop with me everywhere I go. No, I'm not going to host a mail server on my own computer at home (it's a violation of my ISP TOS anyway). No, I'm not going to install an industrial grade UPS for my computer to ensure 99.999% uptime in the face of a power outage either. And, no, I'm not going to custom write an e-mail client which automagically synchronizes its mail read information across other deployments. I've got more important things to do with my time. And, I sure as hell ain't gonna spend the time implementing a Bayesian spam filter with a corpus as big as Google's.

Contradiction: First you wrote "Of course GMail isn't a thin client" and then you wrote "No fat client is ever, ever, as usable as the GMail interface", now... if GMail isn't a thin client, the AFAIK it has to be FatClient... (please do not tell me that you are one of those that believe in the RichInternetApplication hoax) but since "No fat client is ever, ever, as usable as the GMail interface" I guess that makes GMail an OxymoronClient?

The GMail application fills its niche very nearly perfectly. It is everything I've always wanted in an e-mail client, and more.

{GMail uses HtmlDomJsCss, which is not "thin-client" in my book. Medium-client, maybe. Thin, no. -t}

MediumClient? equals OxymoronClient ?

See Also: ThinClientHasFailed

FebruaryZeroNine

EditText of this page (last edited March 2, 2009) or FindPage with title or text search