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.
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? 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). 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. 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 I'll have a look at Edukapp to see if and how it aligns with our ideas, and get back to you on that, 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
