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