Building simplicidade.org: notes, projects, and occasional rants

Google Gear uses

As I said on my previous post, I'm looking over the documentation of the Google Gears (GG) stuff. I read it all yesterday at night, and though about it.

The things I like about GG are pretty simple.

The first one is that you can write your applications to take advantage of it if present, but work the same if not. Its not a all-or-nothing approach, its more of a progressive enhancement thing. It does require discipline, and I would imagine that projects like Jamal or TrimJunction (you can find more here) will soon start appearing everywhere.

The second is latency. If I can cache rarely changed stuff on the client, like list of friends in a social networking site, things that I use all the time in my UI, the latency of the interface is much lower, and therefore the experience much better.

The third is a very decent system for parallel programming on the web. The Erlang fans out there will like the design "share nothing, message passing" system behind the WorkerPool stuff in GG. I do plan to play with this a lot.

Finally, as a co-owner and developer of a e-commerce web site, any processing we can push to the client means less servers we need do deploy centrally and that means less capital investment. And that is definitively a good thing.

There are a couple of things I want to try out in the next few days.

The first one is to write a todo list manager. Its the most simple system you can build and it will allow me to use most of GG functions. the system will seamless synchronize todo items between a Catalyst-powered web app and the offline stuff in GG.

The second one is to try and run a JsJaC instance inside a WorkerPool. This would allow me to run a asynchronous XMPP client inside any web application with ease, making it possible to use the XMPP as push-style communication channel between back-end applications and front-end UI.

This last one is not a end in itself. JsJaC is using polling to connect to a XMPP server. But it allows me to think about a future XMPP DOM standard, available in XMPP clients where we could drop small applications, exchangeable between clients.

But that is last bit is for another brain dump in the near future. :)