On 6 Mar 2012, at 11:02, Niels van Dijk wrote: > 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?
ROLE are involved in EDUKAPP via the OU UK, KU Leuven and IMC. > > 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 >>
