W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: [widgets] Implementing Google Wave with W3C Widgets

From: Scott Wilson <scott.bradley.wilson@gmail.com>
Date: Mon, 8 Jun 2009 22:32:25 +0100
Cc: public-webapps WG <public-webapps@w3.org>
Message-Id: <71AB8C72-3FC4-4FCF-8076-A03A09B026DC@gmail.com>
To: marcosc@opera.com
OK, basically there are two API extensions:

- shared state
- participants

Google has declared its API for these as part of the Wave  
announcement; we have had our own API for quite a while, and for now  
supports both (they are pretty close, and don't clash in use - the  
main difference is we had reused our state API for presence handling  
too, but Wave separates them into two distinct models, which actually  
is pretty sensible). In either case as well as a Widget, and an  
instance of a Widget, you have to introduce the concept of a family of  
Widget instances sharing a common context.

Unlike the OpenSocial spec, the Wave Gadget API doesn't require  using  
a stack of Google JS and other Google technologies in order to work;  
the API is quite simple and easy to implement in a Widget with no  
Google Gadget code.  E.g.

wave.getState() returns a state object (functionally similar to a  
Storage object, but annoyingly not quite the same)
wave.getParticipants() returns objects for each current participant
wave.getViewer() returns an object representing the current user
wave.setStateCallback() sets the function to call whenever the shared  
state is updated

I guess I'm looking at is some shred understanding of how Widgets  
should handle shared state and participant APIs. There are a few  
options:

- use the Google APIs, don't do anything in particular, and hope they  
stay reasonably "open"
- create a new W3C API spec based on the work publicly available, make  
it consistent with other specs (e.g. having Widget.state conform to  
Storage just like Widget.preferences)
- create a Note explaining how W3C Widgets can support Wave Gadget  
APIs, perhaps defining a Feature URI to use for wave

However it also strikes me that this has an overlap with the new W3C  
Social Web group, and so perhaps needs a cross-group discussion as to  
what we think would be a good approach?

S

On 8 Jun 2009, at 19:34, Marcos Caceres wrote:

> 2009/5/31 Scott Wilson <scott.bradley.wilson@gmail.com>:
>> Hi everyone,
>>
>> Something that may be of interest if you've been following the  
>> announcement of Google Wave[1].
>>
>> Back in January we discussed our W3C Widgets implementation  
>> (Wookie[2]), and our extensions to cover shared states and  
>> collaboration[3], a demo of which we brought to the Paris F2F.
>>
>> Well, Google Wave has a very similar API to our own for adding  
>> collaborative Gadgets to waves[4], so we've implemented the draft  
>> API and mapped it onto our existing functionality. We then tested  
>> this by taking the Google Sample Wave Gadgets[5], and converting  
>> them to W3C Widgets (removing Gadget markup, and adding  
>> config.xml). We've then successfully deployed these using Wookie in  
>> a web application (see screenshot[6]).
>>
>> These work pretty much as demonstrated by Google, but using our  
>> existing Wookie codebase, which uses Comet to achieve synchronous  
>> updates between Widget instances.
>>
>> (You can see how the API calls work in the test harness widget on  
>> the left of the screenshot).
>>
>> This raises the question as to whether and how we want to progress  
>> the collaboration/shared state Widget extensions?
>>
>
> I've not looked at this enough to comment, but can you describe what
> you have in mind in a bit more detail. Nice work on integrating the
> Wave stuff so quickly, btw.
>
> -- 
> Marcos Caceres
> http://datadriven.com.au



Received on Monday, 8 June 2009 21:35:39 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT