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 Mon, 06 Jul 2009 08:01:07 GMT
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.

Best,

Scott Wilson


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

On 5 Jul 2009, at 22:38, Sylvain Wallez wrote:

> Ross Gardler wrote:
>> I would like to submit the Wookie project proposal to the Incubator
>> PMC. Our draft is appended to the end of this mail and is available
>> at:
>>
>> http://wiki.apache.org/incubator/WookieProposal
>>
>> A quick overview of Wookie is:
>>
>> Wookie is a Java server application that allows you to upload and
>> deploy widgets for your applications. Wookie is based on the W3C
>> Widgets specification, but widgets can also be included that use
>> extended APIs such as Google Wave Gadgets and OpenSocial.
>>
>> I have agreed to champion and mentor this proposal, Gavin McDonald  
>> has
>> also agreed to mentor, more mentors are being sought - let me know if
>> you are interested.
>>
>> At this stage I am seeking feedback on or questions about the Wookie
>> proposal.  The project team are subscribed to this list and ready to
>> respond to any queries.
>>
>
> The W3C widget spec is more targetted at standalone installation of  
> widgets (like the Mac's Dashboard, Yahoo widgets, Vista widgets,  
> etc) and Wookie as I understand it aims a providing a server-side  
> implementation of this specification. This is an interesting point  
> of view that can allow a wider audience to use this specification  
> that is currently mostly of interest to mobile phone vendors. Now  
> I'm curious to know if a server-side implementation will not hit  
> some technical difficulities related to the implementation of a  
> client-side specification (I saw that already with XForms).
>
> What's interesting also, is that W3C widgets and OpenSocial gadgets  
> are more or less competing specifications, and it seems from this  
> proposal and what I saw in the code that Wookie would like to bridge  
> the gap by providing OpenSocial features to W3C widgets. Is my  
> understanding right?
>
> This looks like an interesting proposal, and I'm willing to help it  
> through incubation if it is accepted by mentoring it.
>
> We must also consider the potential overlap with Shinding and Social  
> Site and see what kind of collaboration (if any) with these projects  
> would make sense.
>
> As a side note, I'd love to run W3C widgets on my Android phone and  
> my iPod Touch. Would client-side implementations of the W3C spec fit  
> in the Wookie project?
>
> Sylvain
>
> -- 
> Sylvain Wallez - http://bluxte.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>


Mime
View raw message