Google answers online state dilemma with non-answer

As I discussed in my previous post There isn't a way to maintain online state with Google Gears. I just found an entry on Google Code which addresses the subject when it comes to database stores. I totally understand Google's point about wanting developers to ensure synchs are reliable and not assume online = success. That still doesn't address my issue with LocalServer rather than the Database module of Gears.

A bit frustrating also is to see that on the same page Google provides essentially the same code I discussed previously to ping the server with AJAX to verify that it is available. GaH! Wasted effort!

I have to say that I do think Google is cutting off it's nose to spite it's face here. While an isOnline() function might be abused when it comes to the local database, it's entirely necessary (as I've demonstrated) for the localServer which is 1/3 of the gears trinity. In addition, I've seen time and time again that you can't use technology to make programmers do their job correctly (I've tried). You have to empower them to make good design decisions on their own, warn them of the pitfalls, and then let them deal with the consequences if they don't do their job well. It's an annoying fact of life in IT (I would know, I've done a lot of cleanup after bad programmers). That's my 2 cents anyhow.

Google gears and the online state dilemma

As I mentioned in my previous post I've been working with Google Gears as of late. Being a greenhorn to this technology (as nearly everyone is since it's pretty new) I found myself considering some fairly serious design questions. The most interesting was "how do I tell if a user is in offline mode (pages and data cached) but has the ability to switch over to online mode?"

Now of course whenever you talk about "modes" in an application it is natural to think about a state machine. That gets a little dicier with the new paradigm introduced with Gears. Since gears runs purely in javascript with a little interaction with the browser plugin, I decided that making an AJAX request for a file that doesn't get cached (as defined in my gears manifest file) was best. If I got the proper contents of that file then I knew the person could swap to online mode, if not then I know they aren't connected. Simple right?

So I thought. Once I whipped up my code I could offline and online my pc and the app was stateful, except of course for a little lag that the ajax request took to timeout when it wasn't ever going to get a response from the server. I included validation based on state to see if I would let the user remove their cached pages and get the online one and everything was happy.

Then I decided to take a look at what I'd done pretending to be a non-technical user. I offlined my app and then watched it. During the lag I noticed that the app state was still online (meaning you could validly switch to online mode) because the first AJAX request hadn't failed yet. So I thought to myself "what if the user took this literally and assumed they were connected via wifi or something and tried to go online?"

The answer: DEATH. Ok not really death but my state machine happily checked its state, saw that it was online, removed all the cached pages and tried to get at the online version of the page. This of course resulted in a 404 as the user wasn't actually connected. No good. My first instinct was that I had to prevent this from ever being a possible scenario because a user would probably freak out.

The half-measure I took to do this was to break out the cache-removing code and not include it on the manifest. Now the user can attempt to remove their cache, but if they aren't actually online they won't find that page and get a 404, but they can back up and the app is still happily serving up cached content while they continue to be offline.

I'm happy with this but not completely. It seems to me (at least so far) that there's no way to conquer this part of the paradigm shift that gears introduces into web applications. No matter how you code around it, the web layer always has a degree of latency associated with it that will allow a window for 404 messages. I hate for the user to see that. I'll update if I figure out a way around this loophole, please comment if you know one ;)

IE duplicates element IDs into the Name attribute, which screwed me up!

ARGH! This one really gets me steamed. It seems that IE has decided that rather than supporting the applicable W3C and ECMA standards, they do what made sense to them. Surprised? I'm not. Anyhow, what the world ends up being stuck with is a scenario where id attributes are mirrored into an invisible name attribute for form elements. Why? So some lazy javascript developer somewhere can erroneously use getElementById('x') to access an element that has the NAME "x" but no the ID "x". I'll spare you the departure into the fact that the frigging function says ID in it and there's another one that uses NAME explicitly. Such mastery of scripting is apparently too much to ask.

That on it's own is lazy, but not terrible. However it turns terrible when you've got some code like this:

<td id="range5"><input type="text" name="range5" /></td>

Now when you submit some perfectly reasonable HTML like this to a web server with a decent browser like firefox you get only 1 element named range5 as you'd expect because you only named one element range5. Try the same with IE and what you'll end up with is a few hours of debugging and cursing the MSoft name. At the end of said debugging you'll find that since IE mirrors the ID attribute into the name attribute (invisibly) The server actually is submitted 2 elements named range5, the first of which in this case has a null value. ARRRRRGH!

So then what is the world left to do about such idiocracy (excellent movie by the by, look it up)? Well, I for one am going to dutifully note this in my "things that suck about IE to think about when coding" list that I always have running around in my head, and not name any IDs the same as NAMEs even though those are supposed to be two distinct entities with no relationship what so ever. IE sucks.