incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Wilson <scott.bradley.wil...@gmail.com>
Subject Re: Proposal for Wookie a W3C Widget/Google Wave widget engine
Date Wed, 08 Jul 2009 16:03:57 GMT
Hi Chris,

Thank you very much for your comments - as one of the initial  
committers I'll try and answer some of the items you've  raised:

1. Terminology

As we are in an area with lots of overlapping specifications I  
completely agree that we need to be careful with terminology.

2. OpenSocial Gadgets

Yes, Wookie supports OpenSocial Gadgets in exactly the way you  
describe, by pulling in the whole Shindig service to create a combined  
servlet application, exposing both the Shindig and Wookie APIs in  
full. However as a convenience we implement  in Wookie some Shindig  
features that would otherwise need to hook into another user- 
implemented backend, such as preference persistence.

You are also correct that someone implementing a Wookie server still  
needs to hook in the Shindig data interface to their social graph data  
to use OpenSocial features. We don't implement this in Wookie;  we  
deliberately keep integration with Shindig lightweight - partly as  
both projects are changing rapidly, and partly as we know users will  
want to wire together parts of the server backend in various ways and  
we don't want to obstruct that if its at all avoidable. So at this  
point I think social graph features are out of scope for Wookie, and  
delegated to Shindig. There is a new social software activity in W3C,  
however this has not identified any specifications; if this W3C group  
did develop a social graph API for Widgets then the project could  
consider whether that ought to be in scope.

I think the governance issues in this space may be a bit off-topic. I  
think however its fair to summarize that this is a complex space with  
overlapping specifications under different models of governance,  
backed by different parties and interests in different sectors, and  
application developers and users are currently caught in the middle of  
it. One of the goals of Wookie is to enable users to make use of great  
widgets/gadgets/apps  in their applications without having to worry  
about any of the backstory.

3. Wave Gadgets

I don't agree with your last point, however:

> 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.

The Google Wave Gadget API consists of two related JavaScript APIs:  
one for shared participants, and one for shared state. As Sylvain  
remarked these are quite simple in principle and are orthogonal to the  
spec used for the packaging and configuration of a Gadget/Widget. In  
Wookie we implemented these APIs and integrated them into support for  
W3C Widgets as an optional feature using Comet to drive state changes  
(an independent OSS Wave Server project, PygoWave, does exactly the  
same thing). This does not require pulling in a communications  
platform, and is supported out of the core architecture that Wookie  
implements for all Widgets.

There has been considerable demand for synchronous collaborative  
widgets that can be embedded in portal-like containers outside of and  
predating Google Wave; for example, several specifications were  
developed and adopted in the elearning market since 2001 to support  
just this use case, and our team defined a specification very similar  
to the Wave Gadget API in 2005 building on this prior work (this is  
why we were able to implement the Wave Gadget API in Wookie within a  
day of its announcement, the first OSS implementation of the Google  
Wave Gadget API).

As Sylvain points out, the main focus of Wookie is W3C Widgets, and so  
we implement the Wave/synchronous collaboration as a Feature extension  
(as defined in W3C Widgets P&C) which is enabled for a Widget only if  
it declares it as a required feature in its config.xml file. Currently  
the code implementing the Wave Gadget API is in its own package  
(widgetservice.feature.wave) and can be built as a standalone  
extension in future builds. The technology enabling it - sibling  
widget instances and Comet - is integrated in the core engine,  
however, as other extension APIs may want to use this mechanism not  
just the Google Wave Gadgets API.

Hope this helps,

- Scott


On 6 Jul 2009, at 13:32, Chris Chabot wrote:

> Hey guys,
>
> Great looking proposal!
>
> On Mon, Jul 6, 2009 at 1:53 PM, Ate Douma <ate@douma.nu> 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:
>   http://code.google.com/apis/gadgets/docs/spec.html 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
>   http://www.opensocial.org/page/opensocial-foundation-faq). The  
> main entry
>   point to find out about OpenSocial is http://www.opensocial.org/  
> and the
>   Shindig reference implementation can be found at
>   http://incubator.apache.org/shindig/
>
>   - 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
>   http://code.google.com/apis/wave/extensions/gadgets/ 
> reference.html), 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.


Mime
View raw message