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? 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
