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