Hi Niels, On 5 Mar 2012, at 13:14, Niels van Dijk wrote:
> Hi Scott > > We have a need for a catalogue with an open interface as well, as we > would like to offer a 'nation-wide' catalogue for higher-ed in The > Netherlands, and allow for easy sharing of gadgets in-between > universitie applications. Ah, good timing :) We have three main stores we're looking at using Edukapp for - a nationwide store for Higher Education in the UK (funded by JISC), an EU-wide store for schools run by EUN, and one aimed at adult learners run by IMC. So we need Edukapp to be as "white label" as possible as each needs its own customisation. (We are also developing a "paradata sharing" module for sharing reviews, download stats, embed stats (etc) across each of the different Edukapp-based stores to help overcome "cold start" issues with individual stores.) > Just recently I wrote a proposal for the OpenSocial 3 spec for this, > blissfully unaware of your work :(. > I already considered in the proposal > the fact that we would want to be able to go beyond OpenSocial gadgets > alone, just as you have proposed. By the way, is there some place I can > have a look at an running version of edukapp? Not at the moment, but I'd be happy to help you get one up and running to play with at your site. > Next to a json api as you propose, we proposed to have a public ATOM > interface. First of all as there are many clients that can consume ATOM > out of the box, also 'non-technical' so to say. This would make public > discovery a bit easier. Whereas JSON would always require a client > implementation. Second thing that we found appealing is the fact that > Atom feeds can be digitally signed, which would allow for a > 'trustworthy' catalogue (much like the model used in e.g. SAML metadata > signing). The current Edukapp API is here: http://code.google.com/p/edukapp/wiki/JsonApi ... though its being continually refactored to make it more RESTful. I think supporting Atom formats make sense too. > > Please find the proposal I wrote here > <http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/e09bae20ac323d5d>, > as well as the small discussion that followed. From the discussion I > took away that such a catalog appliction should probably have a JSON api > to deal with input/output, but would benefit a lot from using ATOM as > its means of 'publishing' the content of the catalogue. I'm also especially interested in embedding, so we've implemented IMS LTI, but also want to integrate Cordova (PhoneGap) to generate hybrid mobile apps for submitted widgets. > Next to the catalog proposal, I also proposed to add some additional > metadata to gadgets as we feel we need this would make exchanging > gadgets/widgets more effective. > After some discussion the proposal now introduces > "terms-of-service","license" and "privacy" information to the metadata > of a gadget, so this can be used directly in the portal catalogue, or in > a catalogue that is independent of the portal running the gadgets. > Please find that discussion here: > https://groups.google.com/forum/#!topic/opensocial-and-gadgets-spec/THK4q32KBhA > I looks like this is going to be part of OS 2.5 License is part of the W3C spec already; ToS and Privacy sound like interesting extensions. For the store itself we've added the various bits of typical app store metadata (tags, comments, ratings) and hooks for recommender systems, and set up the Solr "More Like This" service to recommend similar widgets. > I'll have a look at Edukapp to see if and how it aligns with our ideas, > and get back to you on that, Great - as noted above its already a multi-project collaboration so we're very open to ideas. It may make sense to propose Edukapp for the Incubator if the other current participants are happy with that approach and there is some wider interest - we just needed to kickstart it quickly as there were deadlines looming :) > > Cheers, > Niels > > > On 03/05/2012 12:36 PM, Scott Wilson wrote: >> 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. >> >> 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. >> >> 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.) >> >> 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 > <niels_vandijk.vcf>
