On 5 Mar 2012, at 16:50, Ate Douma wrote: > On 03/05/2012 02:17 PM, Franklin, Matthew B. wrote: >>> -----Original Message----- >>> From: Scott Wilson [mailto:[email protected]] >>> Sent: Monday, March 05, 2012 6:37 AM >>> To: [email protected] >>> Subject: [roadmap] widget catalogs >>> >>> Thanks for getting this started, Ate >>> >>> On 5 Mar 2012, at 02:34, Ate Douma wrote: >>> >>>> * [widget-catalog(s)] external catalogs, shindig v.s. wookie or combined >>> >>> >>> This is something I've been wondering about for some time. At the start of >>> the project we debated the merits of having a built-in widget repository or >>> a >>> separate plugin or even a completely separate project to handle these >>> concerns. In the end we opted for a built-in store as we wanted to have the >>> whole platform available as a single out-of-the-box solution. >>> >>> However now I think we need to look again at this area. >> >> +1 > +1 > > What should be taken into account for this discussion is the distinction > between a widget catalog, which could be multiple and/or external, and > required *internal* runtime meta-data for widgets which actually are in use > within Rave. Currently these two usages are 'blended', e.g. a widget > reference in a page region points to the same registry as used for the widget > catalog/store. > > I fully support using external widget catalogs or registries for adding > widgets to Rave, but we should not be depending on them for actually running > widgets. > > Note: here a major difference comes up between Shindig and Wookie: Shindig > has no persistent view on Gadgets meta-data while Wookie has this 'build-in'. > And Wookie doesn't provide (yet) an SPI to allow 'sharing' this meta-data > with Rave, or even delegating this through an SPI to Rave like Shindig. So > we'll currently need to duplicate at least part of Wookie Widget meta-data in > Rave registry.
I think we have an opportunity to look at the Wookie architecture again in a couple of releases time, and modularising/turning into SPIs some of the capabilities would make sense. Though (like Rave) we do want a working out-of-the-box default implementation. > I also think the use-cases from Scott for Edukapp and Niels for SURFconext > are fundamentally different from more 'standalone' or enterprise/intranet > requirements where strict management and control of the widget catalog, > including ratings, security levels, restricted usages, runtime statistics, > etc. are required. > > I think Rave should provide at least some support for both extreme ends of > this spectrum, as both ends are very real and concrete. > > I'm interested to hear how for instance OMELETTE or SURFconext expect to > handle such things as runtime usage/statistics and administrative control > when delegating to external catalogs. > Multi-tenancy can be a way to solve this, but could or even should we provide > build-in support for such usages in Rave? > Maybe this will always be too custom/specific to generalize. I suspect the > latter but love to hear otherwise. (OMELETTE is more of an enterprise case, and will use an external but still (typically) enterprise-situated store with extra information about things such as QoS and extended lifecycle metadata, particularly for telco-related widgets. EDUKAPP is serving education use-cases where the administrative control and runtime stats make sense delegated to a shared service under (typically) a national-level SLA.) > >> >>> >>> In Wookie there was a realization that things like tags and ratings should >>> not >>> be the concern of the widget runtime, and from 0.10 this concern has been >>> removed entirely. >>> >>> I've also been contributing recently to a project called Edukapp, which is a >>> multi-tenancy widget store/catalog with >>> tags/comments/featured/search/recommendations as its sole concern: >>> >>> http://code.google.com/p/edukapp >>> http://scottbw.wordpress.com/2012/02/27/edukapp-a-white-label-open- >>> source-web-app-store/ >>> >>> ... its still in its early stages, but I'd like to be able to use this with >>> Rave. >> >> I definitely agree that downstream implementers should be able to >> externalize whatever pieces of the widget store that they choose. I can >> also see that many implementers will want different levels of >> customizability in this regard; including being able to aggregate widgets >> from multiple store. > +1 > >> >> I do think Rave will need to offer a default implementation for those >> implementers who don't want to pull in and customize another product; but, >> that is not to say that we shouldn't do a much better job of separating out >> the SPI. > +1 > >> >>> >>> There is also something being developed in the OMELETTE EU project that is >>> quite similar (developed in .NET). >>> >>> One option is to use the existing WidgetRepository API and UI (like the >>> widget >>> picker and UI elements for rating and commenting) but make the service >>> loosely coupled. The current models and backend for the >>> repository/store/catalog concern could go into a separate module or >>> subproject that is configured to be deployed alongside Rave by default >>> (fulfilling the rave-in-a-box requirement), but easily switched out for >>> another >>> implementation, e.g. using REST+JSON. (Eventually the store/catalog may be >>> another ASF project in its own right rather than part of Rave.) >> >> +1. I think an approach along these lines will keep us honest in developing >> the API/SPI but allow for light customization or complete OOTB >> functionality. >> >>> >>> Another is to extricate the whole catalog UI into a separate concern, but >>> that >>> would require a lot more work on both sides - and I'm not sure its worth the >>> effort. >>> >>> S >
