On 5/24/11 4:27 AM, "Scott Wilson" <[email protected]> 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. This option is what I was already working toward :). In addition to being more loosely coupled, this approach provides a path for additional widget types. As Ate already mentioned, it would be good in the future to look at integrating OpenAjax widgets and any other light-weight widget frameworks. > >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. +1. In terms of location for the widget store, I think it is a native function of Rave and belongs up in the Rave box, but that is just my $0.02. > >S
