On 24 May 2011, at 11:33, Niels van Dijk wrote: > Hi Scott, > > To add some comparison considerations: > - Model 1 is 'out of scope' for Rave. It make the gadget/widget > integration a Shindig problem. Rave just consumes what Shindig delivers > - This is a bit bluntly put I must add. > - Also, both gadgets and widgets come from a design philosophy that > integration should be adgile, lightweight and close to the enduser. > Model 2 does that I think. Model 1 looks like a enterprise service bus > to me.
> > One question: are W3C Widgets planning on dealing with (social) data? I did some experimental work with the OS 2.0 javascript API (osapi) in Wookie just to show its possible, but it isn't a core concern for W3C. Where possible the W3C Widget specs delegate their functionality to HTML5 or DAP (e.g. W3C Widget preferences shares the same Storage interface as HTML5 LocalStorage, so you can return window.localStorage as the implementation of widget.preferences if you want to). I'm keeping an eye on the W3C Federated Social Web group in case they have any recommendations here. > > cheers, > Niels > > > On 05/24/2011 10:27 AM, Scott Wilson wrote: >> Hi everyone, >> >> Looking over some of the recent discussions I thought it would be useful to >> clarify how Wookie and Shindig can interact - or remain largely separate - >> in Rave. >> >> I've made a schematic here: >> >> http://dl.dropbox.com/u/4504633/shindig-wookie-rave%20wiring.png >> >> Model 1: Integrated approach >> ======================= >> In the first model, Shindig is integrated with Wookie using the built-in >> integration in Wookie. However, this only provides a unified mechanism to >> acquire and manage widget instances, it doesn't include the capability for >> either registering OSAPI and RPC functions or for handling social data API. >> So Rave provides an SPI connector to Shindig and the OpenSocial JS with the >> OSAPI and RPC functions is made available for all Rave Widgets. >> >> Model 2: Separated approach >> ======================= >> In the second model, Rave connects directly with both Wookie and Shindig and >> has separate rendering processes for each type of Rave Widget (W3C and >> OpenSocial). The two types of Rave Widget are unified for the user through >> discovery in a common Widget Store metadata repository. >> >> Comparison >> ========= >> - Model 1 is simpler if there is always exactly one instance of Wookie and >> Shindig; Model 2 is simpler if there are 0..* instance of each >> - Model 2 has the advantage that there is no dependency on Wookie-Shindig >> integration, which could be broken when either project makes a new release >> - Model 2 has the advantage of letting developers experienced with each >> project to work in a reasonably independent manner >> - Model 1 has the possible advantage that it removes the Preferences concern >> from Rave; conversely with Model 2 Preferences are now stored in two places >> (or Wookie has to be modified to support external preferences storage). >> >> Recommendation >> ============== >> The Wookie-Shindig integration mechanism was designed as a useful >> convenience for anyone wanting to use Shindig for basic gadgets and who >> doesn't want the hassle of sorting the social data APIs out - which is a >> reasonably common use case, but not what Rave is focussed on, which is full >> OS support. >> >> In both cases, the Widget Store could provide lightweight interoperability >> by exposing the set of available Rave Widgets - wherever they come from - in >> a consistent manner. It also makes it clear how we might add other types of >> Rave Widgets in the future. >> >> So, I recommend using Model 2, keeping the Shindig and Wookie integration >> separate, but with a Widget Store (project location TBC) to provide >> consistency, especially at the UI level for users wanting to discover and >> select Rave Widgets to add to their pages without having to worry about what >> kind of server is handling them. >> >> S > <niels_vandijk.vcf>
