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 15:59:00 GMT
Chris Chabot wrote:
> Hey guys,
> Great looking proposal!
> On Mon, Jul 6, 2009 at 1:53 PM, Ate Douma <> wrote:
>> The Wookie proposal has my high interest, especially from the bridging POV
>> between W3C Widgets and Google Gadgets.
> It seems there's a few mixed terminologies here, so in interest of making
> sure we're all talking about the same things I'll quickly go over the
> different types of 'gadgets' that could potentially be supported by Wookie:
>    - Google Gadgets, as described here:
> This is a clasic
>    gadget type model that doesn't have any social tools in it, think clasic
>    iGoogle home page type gadgets.. this actually has the Google brand
>    associated with it and because it's a product name it's called Gadgets (cap
>    G). It's an interesting platform to support, but in general iGoogle is
>    moving to OpenSocial gadgets instead (which is backward compatible).
>    - OpenSocial gadgets not a Google brand or product, instead both the
>    specification process and the reference implementation (Apache Shindig
>    (-incubating)) are community driven. In the beginning it started out with an
>    iGoogle style API but has evolved to a completely different (much more
>    elegant and powerful) platform that has a very large feature set, and
>    focuses on social. Next to that there's the OpenSocial Foundation which has
>    people from many social-interested companies and is a non-profit corporation
>    created to sustain the free and open development of OpenSocial
>    specifications. (more info at
> The main entry
>    point to find out about OpenSocial is and the
>    Shindig reference implementation can be found at
>    - There's mention of 'Wave gadgets', Google Wave uses the same gadgets
>    javascript API, but adds a bit of functionality to it (as described at
>, the
>    added functionality is focused around the real time nature of Google Wave
>    with functions for participants changes and data state changes.
> Now to support Google Gadgets and OpenSocial, the easiest way to accomplish
> that would be to just completely pull in Apache Shindig (-incubating),
> there's a lot more to it then just a bunch of JavaScript API's, there's also
> 3 different rendering models, a REST and JSON-RPC interface to the social
> data with OAuth for authentication, and lots of tricky details to deal with
> things like translations, preferences, security tokens, html/css/image
> rewriting, proxy services, oauth support  and javascript injection and
> dependency parsing. The good news is that all of this is already available
> so mixing it in shouldn't have to be rocket science :)
> To make this work the iframe (that points to the OpenSocial gadget rendering
> end-point) creation is a bit tricky as well, lots of params to deal with,
> and Social Site is a nice demo of how this could be done so you could either
> borrow that code or implement it in a way that makes sense to Wookie.
> OpenSocial does assume you have a social graph though (the activities and
> app data part of OpenSocial are optional, though the platform is more
> attractive if you offer those too), so you could either take Shindig's
> approach and assume that the Wookie users will implement the social data
> interface classes them selves and connect it up to their existing social
> data, and/or you could include Social Site which provides that for you ..
> with some clever crafting supporting both use-cases shouldn't be to bad
> though.
> Google Wave Gadgets is a different beast entirely, they're basically just
> the same gadgets as from OpenSocial, but without the real time Wave server
> behind it that drives the real time data state changes it doesn't seem to
> make a lot of sense to support it in a portal type project, and pulling in a
> complete communications platform might be outside of Wookie's project scope.

Well, the Wave gadget API looks quite simple and doesn't seem to need 
all the complexity of operational transformation required by concurrent 
editing of waves. Looks like a simple Comet server notifying all 
sessions of a given gadget can do the trick, and after a quick look at 
the existing Wookie code, it seems to be more or less how it's implemented.

And this Wave API implementation is also where some overlap can appear 
between Shindig and Wookie. Wookie's primary objective is the 
implementation of the W3C widget specification, while the Wave API 
implementation is more and OpenSocial / Shindig thing.

So I agree with your point, and it will be necessary that the Wookie 
team uses a clear terminology (and project structure?) so that people 
understand what part of Wookie relates to what spec in order to avoid 

This doesn't prevent, however, Wookie to provide complements or 
extensions to Shindig pretty much like SocialSite does.


Sylvain Wallez -

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

View raw message