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
