Hi On 03/05/2012 05:50 PM, 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.
Indeed. I think Rave (or any other 'portal' product implementation) will have its own store containing widgets/gadgets which abide by the rules of the local implementation. A subset of these may have come from (a) remote catalogue(s). Others will be totally local, e.g. from within the campus or enterprise. I could imagine an implementation in Rave where only an admin can configure a remote catalog and move gadgets/widgets from the catalogue to the local store. It would be rater cool and convenient however if Rave could also serve as a supplier of gadgets/widgets from its store towards another endpoint, either a befriended portal or e.g. a national catalogue. This would require the server side of the protocol to be implemented in Rave as a service, whereas the client side would need to be implemented close to the gadget/widget store that is already in Rave. > > 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 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. Well first of all I'm wondering if we are talking about the same think here: I propose to create a exchange mechanism for metadata, *not* for the actual gadgets itself. That means I think at least that e.g. usage is out of scope. The only thing the catalogue can know is how many portals have the gadget definition installed, which says nothing about the actual usage of the gadget. In more general terms I think start with something that makes it possible to exchange gadget definitions. Think of it as an internet exchange. The definition is there, the technical requirements are met. How and under what conditions one wants to use the gadgets is up to the supplier of the gadget and the party integrating it into its portal. If we take that route, we may not even have to deal with stuff like security levels, restricted usages etc, as that is not up to the catalog, but up to the parties picking it up. The catalogue should be able to inform (e.g. via terms-of-service), but not to enforce. By the way I know the people of ROLE (http://www.role-project.eu/) are esp. interested in have a catalogue + API es well, and I could imagine the Sakai community thinking about this too. Are any of these currently involved/ aware? cheers, Niels > >> >>> >>> 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 >
