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