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