Now that I'm writing in public, it feels like I have a backlog of ideas I need to spit out. Here's another of those "noteboook ideas". It pre-dates my "Func-y JS" idea, but stems from the same "trends in hacking" meme.
Say you want to write a client/server GUI application with as little logic as possible on the client. Traditionally, this means: X-Windows, VNC, Windows RDC, or other Remote Desktop Software. Some of these are OS-specific (Windows, Unix). All of these assume that the server authenticates the user before the app is used.
Informally speaking, the server "knows who the user is" before the app can be seen or used.
Contrast this with the web world. Web apps are supposed to be OS-agnostic, and nominally open for "public" usage. Anyone who's built a web storefront, and watched their conversion rates, knows that requiring a user to register prior to checking out means many lost sales. Users don't like to authenticate first for anything, even when their credit card is involved.
So how can we combine the web's "anybody is welcome" ethos with a full client/server GUI. AJAX is one approach. But what if we really want all logic on the server, ala X-Windows? Why might we want this?
- Minimizing client code -> minimizing cross-platform workarounds
- One client -> multiple apps
- Option to insert advertising into the app (free, yet monetized)
- Multi-user experience
Games are sort of an obvious candidate here, but keep client/server latency in mind as a design constraint. A first-person shooter like "Doom" probably won't work with ~70ms latency and all logic on the server. On the other hand, a turn-based game like Scrabulous might work very nicely.
How is Scrabulous implemented today?
- Standalone: Java
- Facebook app: either FBML or external html... only options Facebook provides
- They also have an "email-based" game
I was writing Scrabulous, I'd hate to implement the same game 2, 3, or more times. Can we unify these approaches somehow?
Madcap Idea: "Remote <canvas> Protocol"
<canvas> is an HTML element introduced by Safari, now supported in Firefox and part of HTML5. It's possible to emulate <canvas> in Internet Explorer without plugins – Google does this today on Google Maps.
Per Wikipedia:
Canvas consists of a drawable region defined in HTML code with height and width attributes. JavaScript code may access the area through a full set of drawing functions similar to other common 2D APIs, thus allowing for dynamically generated graphics. Some anticipated uses of the canvas include building graphs, animations, games, and image composition.
Sweet! It's a simple but full-blown 2D API, already cross-platform and standardized. But it's accessible only to client-side JavaScript. How do we move our "application logic" to the server? Write a small bit of client-side JavaScript that:
- Opens one XMLHttpRequest to the server
- Read rendering commands from here and relay to the canvas
- Set event handlers to capture user clicks & keystrokes on the canvas
- Relay user clicks & keystrokes back to the server over a 2nd XMLHttpRequest, or the first one if that's possible
Gee, that sounds pretty simple. Can this possibly work? I may have to throw together a proof-of-concept to find out. :-)
