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 hasalso 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
smime.p7s
Description: S/MIME cryptographic signature
