A journal that focuses on Flash Platform development, and a little bit about what I am up to on any given day.

Thursday, April 20, 2006

Off to FITC

So just like many others I am on the way to Flash in the Can this afternoon.

I have many things on my slate this year to do while I am there:

1/ We are looking to hire Flash/Flex developers and a designer. I am going to be looking to talk to people to fill the positions we have, so if you are looking for a job developing advanced Rich Internet Applications, please come and talk to me.

2/We have 2 RIA's up for awards at the event. The SNL Merger Model is up for Technical Excellence, and UpdateHollywood (first channel built on the PermissionTV platform) is up for Converging Media. Hopefully we will walk away with an award. Eric Chan is also up for the Best Student Portfolio Award.

3/I have to sport my Brian McGrattan sens jersey on Friday and Sunday due to the fact that the Sens start their big playoff run.

I will be at the conference hanging with Stacey(bitchwhocodes) , Eric Chan, Paolo Farago, and Steve MacKenzie, all from our office.

Feel free to come up and say hi, and... ummmm, drink a few beers.

Monday, April 17, 2006

Peldi on REST

I just read Peldi's post on REST.

After reading the article, a few things came to my mind as a Rich Internet Application Developer:

First off, when it comes to REST, things can get a little confused and the term ends up being used loosely. When you talk about "State Transfer" is that "Model State" , "View State", or "Application State" (the latter being a combination of both).

REST can be used very effectively when web services are being delivered, where the state transfer is that of "Model State". The Flickr REST API is a great example of this:

Template Flickr Request:

Flickr claims that this is the format of their REST API, but this is not in agreement with what is truly considered REST because it is triggering action, and not transfering state(all the time). I could use this API to delete photos, return photolists, and add tags to photos.

However, the point of the Flickr API is not to be human readable, it is instead a way to allow ubquitous intercommunication with any remote application that can communicate via HTTP. It is used primarily to transfer "Model State". Is it REST?, not completely, so maybe all the web 2.0 companies out there offering up REST API's should consider a new term.

So that takes me to "View State". REST is used to describle this as well. Over the years Flash developers like Robert Penner, worked hard to develop ways to allow Flash content to interoperate with traditional web browser navigational mechanisms. By that I mean, Back/Forward Buttons, Bookmarking, or really just all history management in the browser.

The solution, which is now built into Flex as the HistoryManager, uses a hidden HTML frame that carries params on the url that gets communicated back to the SWF as hidden pages load in and out of that frame:

Flex History REST URI

The funny thing is, that this is extremely RESTful. You are transferring the state of the view very specifically. However, you are not really providing a pointer to any specific resource, you are just simply conveying the state of the UI that wraps an application that likely has a separate "Model State" not represented in this URI.

So that leads us to "Application State", and this is the state that Peldi and the others are discussing. This is when both the "Model State" and the "View State" are being conveyed in the same URI:

Teknision on Google Maps (ugly):

Peldi's Delicious Links about APIs (beautiful):

Now whether the links are beautiful or not, both are very useful. but the real question is:

"Why is one beautiful and the others are not?"

The Delicious example is communicating a logical breadcumb of organizational structure, and that is why it is beautiful.

The Google Maps example is not beautiful because the parameters are siblings, not descendants. REST looks beautiful when representing a simple descending navigational structure, but looks awful when more and more siblings come into play. As a matter of fact, in a URI, siblings will block further decent.

It is due to this that REST is truly not the ultimate format for state transfer.

And this is where I conclude with the reason why Rich Internet Applications and REST(from a web browser perspective) has always been a complicated situation and will continue to be:

Web Browsers force us to communicate "Application State", where Rich Internet Applications don't really have a strong constant definition of "Application State". They instead manage "Model State" and "View State" separately and it is that that makes them so powerful and appealing. Because the Browser is the host for the RIA, the RIA is forced to find a way to separate the two states out of the constraints of the Browser enviornment.


In a way REST is lovely, but it is lovely in it's simplicity. When it comes to Rich Internet Applications, we must remember that the concept of the RIA was developed because we believed that the traditional REST model of the Internet was not adequate to facilitate the experiences and applications we all wanted to deliver over the internet.

While I believe it is important for RIA developers to work hard to try and fit into a REST driven web, I think it is more imprtant to prove to the rest of the web industry that REST is not the answer to every problem, and is not powerful enough to communicate everything that we need to communicate.

Sunday, April 02, 2006

PermissionTV Gets nominated as well!


just noticed that our internet TV channel application PermissionTV got a nomination in the Convergence category at Flash in the Can as well! It is for the first public channel called UpdateHollywood:




the Mighty merger Model gets nominated!

Well our monster RIA we developed for SNL Financial got nominated for technical excellence in the FITC awards:


SNL Merger Model RIA Preview

Hope we win, worked really hard on that one. It can be really hard to communicate it's value to most though as the target audience for it is invesment bankers. We shall see.