Monday, October 25, 2010

Eliminating the Need for Flash

HTML5 and related technologies are getting more powerful every day and for me as a web developer it feels good that it becomes possible to build event more things that would have been the domain of "Flash Developers" a couple years ago (if not event cooler stuff). And, actually, I was using Flash myself to make things work back in those days.

Still there are two things that would still make me pick Flash as the technology of choice and I don't like that, so we should fix it!

1. Fullscreen
Fullscreen is awesome. Even Steve Jobs thinks so. I personally think we should do something really simple to fix this:'/my/path', '_fullscreen') already has all the security restrictions in place that we expect from a modern browser with a built in popup blocker. There might need to be extra restrictions with respect to keyboard events (so that pressing ESC always takes you back) but even not having keyboard events at all would be fine for a start.

2. Ease of Deployment
The deployment story for Flash is awesome. Send someone a SWF file, he can play it. Yes, for more advanced use cases the file might reference a couple XML files and other asset and might need some parameters to get going but overall that's it.
If you haven't worked in big multi-Agency projects (which would be a good thing :) you might not appreciate this point as important but it really makes sense to have an exchange format for content which one can just "drop" into what is already there.
I don't personally have the perfect solution for SWF like deployment of HTML content but at least I have an idea: Putting HTML files and related assets in a ZIP file and then delivering the ZIP file to the browser which would be smart enough to unzip the file, stick it into an iframe and display everything. I played around with doing all of that with just a little bit of JavaScript. It kinda worked but is nowhere near a fully transparent abstraction.

Tuesday, October 12, 2010

Access to WebSockets on a Sub-Domain though a Proxy iFrame

One of the current design mistakes of Streamie is that the WebSocket server is hosted on the same domain as the main web server. At first this seems like a good idea and the HTTP-upgrade-style implementation of web sockets seem to be made for this approach. Here is why this is still a bad idea:

Scaling web servers is a different task from scaling web socket servers (e.g. because HTTP is inherently stateless while web sockets are inherently stateful and many other reasons). Thus my recommendation is to always host your web socket service on a different domain to enable hosting it on a different infrastructure.

While native web sockets make cross domain access easy this is no longer true when you start using all the work arounds (e.g. by using like XHR long-polling, multi-part XHR and html-files.
It is important to note that even for clients that do support web sockets often you cannot use them because popular web proxies such as squid do not support web sockets.

Access your web socket service through a proxy iframe. This invisible iframe is hosted on the domain of your web socket server and is embedded in your main page. Then access the iframe though the use of document.domain or postMessage. A similar technique (albeit not actually for accessing web sockets is being implemented by #newtwitter. See the source and look for an iframe to

Thursday, October 7, 2010

Streamie now runs on Twitter Site Streams

The production environment of Streamie was just switched over to use the Twitter Site Stream API for backend connectivity. (The code for this currently lives in a branch).
With site streams the server only opens a single connection for every 1000 users. Twitter then sends the events of all users over this single connection. The node.js app uses a simple single process message queue to distribute the messages to the actual clients.
If you are running your own streamie server there should be no changes. Site streams are only available to privileged users. If you do not have access, streamie will transparently fall back to user streams. However, the site branch also introduces the usage of a JSON based config file for the server (instead of the ugly command line parameters).

Sunday, October 3, 2010

Joose Blog

I haven't been blogging on Joose here for a while. Check out the official Joose blog for that.