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
>