On 6 Mar 2012, at 12:01, Ate Douma wrote: > 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.
Things like user reviews, ratings, and number of embeds/downloads are relevant to a type "a" store, but it wouldn't and couldn't rely on applications downloading or embedding widgets to pass any of its local runtime information back. So the UC from a Rave point of view would be along the lines of a Rave admin or Rave workspace owner going to the store and finding widgets to install in Rave, which are then run by Rave locally. In the simplest case, they go to the store website and find the XML URL for the gadget, or the .wgt download URL for the widget, and add it to Rave directly. In the more advanced case, browsing the store and selecting widgets to import is integrated with Rave's local store. Marketplace APIs are therefore mostly oriented towards discovery - search, browsing by tags, featured widgets etc. This should be fairly simple for Rave to both consume from the marketplace, and expose if Rave is acting as a marketplace. (I have thought a couple of times about using Rave itself for the market infrastructure, it makes sense in some ways) For other applications that don't have any native widget runtime capabilities then the store could support embedding using APIs such as IMS LTI - but thats not so relevant to Rave. > >> >>> 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 >
