Thanks Scott for writing this up and providing better insight in these
approaches!
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.
+1
I'm also in favor of this approach, with the added question if we cannot also
bring the Wookie Preferences within Rave through a Wookie provided SPI layer.
That way these widget/gadget engines, and hopefully others too, can be managed
and integrated in a generalized way. Furthermore, it should allow for much more
flexible scaling where the management and integration of multiple instances of
Wookie/Shindig servers is under the control of Rave and not (no longer) a
concern of these engines themselves.
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.
The Widget Store/Repository IMO should belong to Rave (see also my reply to the
proposal of Ross).
Especially the Widget Repository will need to provide much more than just a
"store" solution and will need a high level of customization and extendability
to support features like access privileges, ratings, recommendations,
"temporarily taking offline" etc. which much more belong to and are tied into a
specific Rave instance and its specific usage and less usable and meaningful out
of its context.
Thanks,
Ate
S
