open hack 08
I was one of the lucky ones to participate in Yahoo!'s open hack day today. Yeah! I got a t-shirt, a thermos bottle, and a whole bunch of stickers. I got to learn some new stuff as well.
The goal of the 2-day event is mostly to introduce the latest API developments at Yahoo!, to the web developer community. Among the represented technos where flickr, fire eagle, yahoo's mail, music, search, geo, apis, and more. I could not see everything, and focused mostly on learning about Yahoo! Application platform, which the Yahoo! folks let us preview.
The general idea is this: 1. Centralize all the profile and social graph information currently help in the various Yahoo! properties. 2. Provide APIs to access all that good stuff. 3. Align these APIs with the opensocial spec whenever applicable.
As an opensocial application developer, the prospect of the giant Yahoo becoming the next opensocial container on the block is fascinating. This can potentially make myspace - the current behemoth - look like like an upstart.
Well, not so fast. There are a lot of tricky problems to solve, not the least of which is how you merge the relationships you have built on flickr, yahoo messenger, contacts, 360, etc... Still, this is very promising, so I decided to turn one of my zembly widgets into a yap opensocial application. Unfortunately, my initial excitement was quickly tempered by the following setbacks.
First, YAP does not take a gadget XML as input. Instead you have to give it a URL to the html page. No biggie. Juts give it the widget iframe link
Next obstacle: no external script is allowed. My widget used prototype.js methods, so I took out the prototype dependency and implemented replacements in my widget. Good thing I was not using much. I also had to inline in my widget the zembly gadget time (things-gadgets.js).
Next obstacle: YAP uses Caja... And Caja did not like many things about my widget. If you claim that your widget is xhtml, as in
it will parse it as xml. It tripped on the first lower-than comparison in the script, thinking it was a new element.
The trick here was to convert the statement into a greater-than comparison.
Then Caja fussed about a bunch of javascript syntax issues. One Caja rule I ran against is the global scope leaking problem. Supporting Caja in zembly is going to require some work on the part of widget developers.
In the end, some of the caja errors where due to zembly the widget runtime, which I could not hack, so my first yap app never ran. I was able to turn my code into something caja compliant. In the process I found the caja test bed to be very useful.
Aside from hacking, another interesting talk was about an experiment by a Yahoo! team in building a complete app on myspace. Here is a summary of their findings was:
Pleasure:
* Documentation (opensocial, myspace)
* Plain standard stuff (no FBML, FBJS, or other proprietary language)
* ability to quickly move to another container
Pain
* unpredictable caching
* platform outages
* lack of communication regarding changes in platform
* inconsistent spec file support between containers
* UI load time. It takes time to go and fetch the data after load and it does affect the user experience. The team even suggested server-side UI rendering backed up with REST services calls, and combined with doing a document.write() in the gadget UI code.
The goal of the 2-day event is mostly to introduce the latest API developments at Yahoo!, to the web developer community. Among the represented technos where flickr, fire eagle, yahoo's mail, music, search, geo, apis, and more. I could not see everything, and focused mostly on learning about Yahoo! Application platform, which the Yahoo! folks let us preview.
The general idea is this: 1. Centralize all the profile and social graph information currently help in the various Yahoo! properties. 2. Provide APIs to access all that good stuff. 3. Align these APIs with the opensocial spec whenever applicable.
As an opensocial application developer, the prospect of the giant Yahoo becoming the next opensocial container on the block is fascinating. This can potentially make myspace - the current behemoth - look like like an upstart.
Well, not so fast. There are a lot of tricky problems to solve, not the least of which is how you merge the relationships you have built on flickr, yahoo messenger, contacts, 360, etc... Still, this is very promising, so I decided to turn one of my zembly widgets into a yap opensocial application. Unfortunately, my initial excitement was quickly tempered by the following setbacks.
First, YAP does not take a gadget XML as input. Instead you have to give it a URL to the html page. No biggie. Juts give it the widget iframe link
Next obstacle: no external script is allowed. My widget used prototype.js methods, so I took out the prototype dependency and implemented replacements in my widget. Good thing I was not using much. I also had to inline in my widget the zembly gadget time (things-gadgets.js).
Next obstacle: YAP uses Caja... And Caja did not like many things about my widget. If you claim that your widget is xhtml, as in
<html xmlns="http://www.w3.org/1999/xhtml">
it will parse it as xml. It tripped on the first lower-than comparison in the script, thinking it was a new element.
if (cur < startIndex) {
The trick here was to convert the statement into a greater-than comparison.
if (startIndex > cur) {
Then Caja fussed about a bunch of javascript syntax issues. One Caja rule I ran against is the global scope leaking problem. Supporting Caja in zembly is going to require some work on the part of widget developers.
In the end, some of the caja errors where due to zembly the widget runtime, which I could not hack, so my first yap app never ran. I was able to turn my code into something caja compliant. In the process I found the caja test bed to be very useful.
Aside from hacking, another interesting talk was about an experiment by a Yahoo! team in building a complete app on myspace. Here is a summary of their findings was:
Pleasure:
* Documentation (opensocial, myspace)
* Plain standard stuff (no FBML, FBJS, or other proprietary language)
* ability to quickly move to another container
Pain
* unpredictable caching
* platform outages
* lack of communication regarding changes in platform
* inconsistent spec file support between containers
* UI load time. It takes time to go and fetch the data after load and it does affect the user experience. The team even suggested server-side UI rendering backed up with REST services calls, and combined with doing a document.write() in the gadget UI code.
Labels: caja, openhack, opensocial, yahoo
posted by Jacques Belissent at
10:14 PM
0 Comments:
Post a Comment
<< Home