On 03/06/2012 10:39 AM, Ross Gardler wrote:
On 5 March 2012 16:50, Ate Douma<[email protected]> 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
I'm pleased to see this coming around again. I was never happy with
the original decision but given that I was not going to start coding
an alternative I got out the way since my preferred route certainly
has more overhead. Today, unfortunately, I am still unlikely to start
coding in the foreseeable future so as with previous discussions treat
my position as that of a user making (unreasonable?) demands on your
time ;-)
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.
+1
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'm not quite following this. I agree the use-cases are different but
they are not *that* different, it's only a matter of emphasising
different features. I imagine the majority of features will be
required in both use-cases. An education-wide repository will still
require "management and control of the widget catalog, including
ratings, security levels, restricted usages, runtime statistics, etc."
- the only word I have stripped from Ate's post is there is "strict."
I guess this means that those with the less strict use case will focus
on things like "runtime statistics" and "ratings" while those with the
more strict requirements will focus on things like "security levels"
and "restricted usage".
I think the response from Niels helped me to get this more clearer.
For a large part we seem to have been mixing two different types of catalogs in
the discussion. See also my response to Niels email on that.
For catalogs of type a) or maybe termed 'widget marketplace' I don't think it
makes sense to manage things like security levels or runtime statistics: those
likely are and can only be relevant to the local portal usage. I don't see how
you could or even would want to maintain these on an education-wide/federated
repository.
I think Rave should provide at least some support for both extreme ends of
this spectrum, as both ends are very real and concrete.
Does this mean the first step is to agree a required feature set at
both ends of the spectrum? From there we should agree an API that both
Wookie and Rave will use. I imagine that attempting to define those
features will clearly indicate whether the differences are
insurmountable or not.
I still think we're mixing two different catalogs here: I don't see how or why
Wookie should be on a different end of the spectrum from Rave.
But the two type catalog types do share a lot of functionality, and the
'standard' features for a type a) or widget marketplace catalog probably is only
subset of the features a type b) or local widget repository will need to
implement. So it should be possible to expose a local widget repository also as
a widget marketplace, but not the other way around.
Ross
