incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Proposal for Wookie a W3C Widget/Google Wave widget engine
Date Mon, 06 Jul 2009 08:32:57 GMT
Scott Wilson wrote:
> Hi Sylvain,
> I'm Scott Wilson, one of the named committers on the Wookie proposal; 
> I'm also a contributor to the W3C Widgets family of specifications.
> You are right in your assessment; W3C Widgets and Google Gadgets are 
> indeed potential competing specifications for web widgets, despite the 
> scoping statement in the W3C Landscape document that tries to make a 
> hard distinction - this is more for political than technical reasons, 
> as when you dig into the technology its clearer applicable in a wide 
> range of environments.
> Because of this we are keen to enable platform developers and widget 
> developers to avoid having to make a strong choice now between Google 
> and W3C, and for users to need to distinguish between widgets/gadgets 
> developed for mobile, desktop or web use, or which spec its been 
> written to. We've also successfully integrated the Google Wave Gadget 
> API with W3C Widgets*, an example of "mixing and matching" Widget 
> standards.
> We currently embed Shindig as a component in deployments, and connect 
> together the APIs where we can - for example, we implement the 
> "setPrefs" feature of Shindig by connecting it up to our 
> implementation of the W3C Preferences API (itself derived from HTML 5 
> Storage). It would be good to explore further collaboration as the 
> implementation of the two spec families may follow a common path. 
> We've adopted some patterns used in Shindig where appropriate (however 
> its worth noting that implementing the W3C spec is far more 
> straightforward than implementing Gadgets and OpenSocial).
> We've also been working with the Sakai3 project which have already 
> been using Shindig, and have recently been experimenting with Wookie 
> for the reason stated above - to transparently offer choice to their 
> users of widgets using both W3C and Google spec families.
> On the client implementations side: I think we should look at 
> splitting out some of the parts of the system into libraries that can 
> be reused in client implementations - I know a few people who are 
> already interested in doing some Android and iPhone apps - for 
> example, a framework that "wraps" a W3C Widget in an iPhone container 
> for submission to the App Store. Peter Paul Koch has also been 
> lobbying Google to support W3C Widgets in Android natively, and it has 
> also been discussed in the Android OSS community as a good idea for a 
> potential community project.
> On implementation - so far we haven't come across any major issues in 
> moving from client to server-side other than same domain/cross-site 
> access, which we solve via server-side proxying (exactly the same as 
> Shindig - in fact we have a config switch that lets deployments use 
> Shindig's proxy rather than ours). However I think looking forward it 
> would be good to consider CouchDB and Cassandra for storing Widget 
> state data (preferences and shared states) rather than MySQL as 
> key/value persistence is a good fit for widget states, and this may 
> perform better under high load situations.
> I hope this answers your questions.

Yes, it does! And this makes this project even more interesting.

On the client side, you can certainly count me in, since developing 
Android and iPhone apps is part of my day job.

I'm also particularly interested in the Wave API as a way to develop 
collaborative widgets, something that has been missing up to now in the 
various widget specs.

> * Our team had originally implemented functionality equivalent to the 
> Google Wave Gadget API as an extension of W3C Widgets around 18 months 
> before the Google announcement, but adopted the Google API for 
> pragmatic reasons - we'd rather follow specs than create them.

And this is a wise decision IMHO.



Sylvain Wallez -

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message