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