On 6 Mar 2012, at 12:54, Ate Douma wrote: > On 03/06/2012 01:22 PM, Scott Wilson wrote: >> >> 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) > Actually that seems like a compelling case for Rave to me. > If I would want to provide a widget market I'd like it to also show 'demo' > usages, meaning it should actually be capable to run and show these widgets > within the widget market itself. > A standalone meta-data providing only widget market sound dull to me.
Exactly - the prototype we have now already uses Wookie for live widgets in the market, but doing them same with Shindig for OpenSocial gadgets its much trickier, so reusing Rave does make a lot of sense from that point of view. Also may of the pieces (JPA, Shiro, Jackson, Shindig, Wookie...) are common anyway. The things we need to add, such as Solr for search and similarity matching and hooks for recommenders, may be good additions to the Rave core anyway. Kris and I were discussing this idea today and TBH went back and forth on it quite a few times on the pros and cons...I think we may just have to give it a try and see how well it seems to fit. > >> >> 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 >>> >> >
