Makes me think we need a new instance of Zawinski’s Law for software platforms, something like: “Every platform attempts to expand until it can run Unix…”

I’ve bootstrapped Trifle as a simple read-only tagbase browser. The client receives data as JavaScript, which works great. Now I need to handle the other direction: JavaScript code posting updates to the server. But whatever code is running on the server, it probably won’t be JavaScript, so sending data in JavaScript form is pointless.

I could try to get sneaky and take advantage of the extreme similarity of JavaScript and Python data notation: lists, dictionaries, strings, and numbers have almost identical syntax. That would inevitably bite back, though, especially the “almost”.

So what other format would be easy for JavaScript to generate and for your average text-munging language to parse? Yes, there’s XML, but the DOM (for generating it) isn’t what I’d call convenient. Maybe a simple line-based text format will fit the bill. A general “verb url data” syntax could cover everything I need.

And no, it’s not like I’m abandoning XML. I’ll eventually extend the server side of Trifle to accept and generate XML, so that it plays well with others. For direct server-to-JavaScript-client communication, though, XML doesn’t cut it in this case.

Some apps, like GMail, just ignore the problem, and thus prevent deep linking. Google Maps uses a workaround: a link on the page itself that gives you a bookmarkable version of the current page. But can we do better?

There is a way to change the URL in the address bar without causing a reload: just set location.hash. The value is tacked on to the displayed URL (plus a ‘#’, of course), and gets saved in bookmarks. When a bookmark is used, that part of the URL isn’t sent to the server, but we’re assuming a script-heavy web application anyway: just check for the location.hash value in an onload handler.

There’s a snag, though. If the user is already at “http://your/url/#foo” and navigates to “http://your/url/#bar” (via another bookmark, for instance), the browser won’t tell you about the change. Other than fantasizing about an onhashchange event, there’s not much you can do about it. Well, you can use setInterval() to poll location.hash for changes, but you’re stuck between having a long gap between checks—and therefore slow update performance—or slowing things down with frequent checks.

So is there no good solution for web-app bookmarkability? Not that I’ve found.

TrimPath is a relatively new umbrella project for just that. It currently houses three projects: a client-side templating library, a DSL for SQL-esque queries, and a spreadsheet engine. Steve Yen is the instigator and author of these projects; he has a blog on the TrimPath site.

Good stuff, and we need more of it. Which, in the open-source world, means that I should be doing more of it. Okay, I’m off to program.