Hi, On 03/06/2012 12:38 PM, Ate Douma wrote: > On 03/06/2012 12:02 PM, 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. > > Right, this is more inline with how I envisioned it. > This would mean we are talking about two different catalog usages: > a) external catalog(s) which can be used by a portal *administrator* > to retrieve widgets from to be installed in a local catalog > b) a (single) local catalog which becomes available to portal users to > select available widgets from to use within the portal > > Features like runtime statistics, security control/configuration, > (internal) widget ratings, etc. then only apply to the local catalog (b). > Furthermore, external catalogs (a) are probably never or at least > unlikely to be exposed to end-users who are allowed to add new widgets > to portal pages. > > IMO the discussion here then should focus around this local (single) > catalog (type b) and if for Rave we should have this 'build-in' or > (optionally) use a standalone 'widget catalog' application (from a > separate/external project) instead.
Yes I fully agree. It would be nice however to have a 'module' in Rave that would allow a Rave admin to 'publish' to the 'widget catalog' application (from a separate/external project) so this would basically mean both Rave and the 'widget catalog' share a common API for doing so. This would make building the content of a 'widget catalog' much easier. Cheers, Niels > > The fundamental question is: can we rely and depend on an external > standalone widget catalog project to provide and fulfill all our > requirements, including support for our Rave generalization of widgets > (both OpenSocial & W3C Widgets), security integration (using and > depending on Rave security models), tagging, grouping, etc.? > > For the more generic and shared catalogs of type a) I definitely see > the need and feasibility to create a standalone project for. > >> >> 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. >> > If there would be a 'standard' protocol for catalogs of type a) I > think it should definitely be possible and useful for Rave to also > implement this protocol on top of its own local catalog. IMO such a > standard widget catalog protocol will always cover only a subset of > the requirements for a local catalog. > >> >>> >>> 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. > Yes, thanks for clearing this up already above. > I agree: we've been mixing two types of catalogs in this discussion. > > Maybe we can come up with different terms for these different types. > Type a) sounds more like an (open) widget marketplace, while type b) > might be better termed an internal widget registry or repository? > >> 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. > I'm not even sure the catalog can or should know if/where a widget is > 'cloned' for usage in a portal. > >> >> 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. > +1 > >> >> 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 >>> >
