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 >
