Wiring up Wookie and Shindig with Rave: Comparison of two approaches

[Scott Wilson <sc...@gmail.com>]

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

Re: Wiring up Wookie and Shindig with Rave: Comparison of two approaches

[Scott Wilson <sc...@gmail.com>]

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>

Re: Wiring up Wookie and Shindig with Rave: Comparison of two approaches

[Niels van Dijk <ni...@surfnet.nl>]

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

Widget Store (was: Wiring up Wookie and Shindig with Rave: Comparison of two approaches)

[Scott Wilson <sc...@gmail.com>]

On 25 May 2011, at 10:51, Ate Douma wrote:

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

I need to do something very much like a "widget store" for several other projects, some using LifeRay, one hopefully Rave.

My current favourite approach to the "widget store" implementation is to use an Apache Solr index with a REST API for the core domain objects (Widget, Review, Rating). Solr is treated as an index you can push metadata into from the portal - so push in a review or rating - or pull from the widget server - so pull in Widget metadata from Wookie or Shindig.  I've got some work-in-progress here for this:

https://iecbolton.jira.com/svn/ITEC/widget_discovery_service/trunk/

I don't think there is any conflict between having a generic widget store API and Rave-specific domain objects, views and controllers. For example, Rave could create and persist a Review model, but also push this into the Widget Store for indexing.

(Slightly more complicated: I may try and use Rave as the front-end for a white-label widget "app store", but I don't want to really go into that now as it might tie the discussion in knots.)

> 
> Thanks,
> 
> Ate
> 
>> 
>> S
> 

Re: Wiring up Wookie and Shindig with Rave: Comparison of two approaches

[Ate Douma <at...@douma.nu>]

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

Re: Wiring up Wookie and Shindig with Rave: Comparison of two approaches

["Franklin, Matthew B." <mf...@mitre.org>]

On 5/24/11 4:27 AM, "Scott Wilson" <sc...@gmail.com> 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