- From: Scott Wilson <scott.bradley.wilson@gmail.com>
- Date: Mon, 8 Jun 2009 22:32:25 +0100
- To: marcosc@opera.com
- Cc: public-webapps WG <public-webapps@w3.org>
- Message-Id: <71AB8C72-3FC4-4FCF-8076-A03A09B026DC@gmail.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
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Monday, 8 June 2009 21:35:39 UTC