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. TerminologyAs we are in an area with lots of overlapping specifications I completely agree that we need to be careful with terminology.
2. OpenSocial GadgetsYes, 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 <a...@douma.nu> wrote:The Wookie proposal has my high interest, especially from the bridging POVbetween W3C Widgets and Google Gadgets.It seems there's a few mixed terminologies here, so in interest of makingsure we're all talking about the same things I'll quickly go over thedifferent 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 clasicgadget type model that doesn't have any social tools in it, think clasiciGoogle home page type gadgets.. this actually has the Google brandassociated 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 ismoving to OpenSocial gadgets instead (which is backward compatible). - OpenSocial gadgets not a Google brand or product, instead both thespecification 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 corporationcreated to sustain the free and open development of OpenSocial specifications. (more info athttp://www.opensocial.org/page/opensocial-foundation-faq). The main entry point to find out about OpenSocial is http://www.opensocial.org/ and theShindig 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 Wavewith functions for participants changes and data state changes.Now to support Google Gadgets and OpenSocial, the easiest way to accomplishthat 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 withthings like translations, preferences, security tokens, html/css/image rewriting, proxy services, oauth support and javascript injection anddependency parsing. The good news is that all of this is already availableso 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 eitherborrow that code or implement it in a way that makes sense to Wookie.OpenSocial does assume you have a social graph though (the activities andapp data part of OpenSocial are optional, though the platform is more attractive if you offer those too), so you could either take Shindig'sapproach 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 badthough.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.
smime.p7s
Description: S/MIME cryptographic signature
