On 17 May 2011, at 15:42, Ross Gardler wrote: > On 17/05/2011 14:31, Ate Douma wrote: >> Great to see this proposal Ross! >> >> Of course, it immediately raises many questions (cool!), which also >> means that right now its not clear enough to me if and how we can or >> want to do it (exactly) like you propose.
So here I think we're looking at using Rave to not only deliver Rave's management UI using Rave Widgets, but also providing the management UI for the components it builds on (Shindig and Wookie). It sounds quite similar to the WSO2 "Carbon" stack, which uses OpenSocial gadgets to provide the management UI for all its components that don't necessarily offer their own management or monitoring UI. >> >> But before I'll bring up the questions concerning the proposal itself, >> I'd like to express my worry about the overloading of the term Widget, >> especially in this context (not just this proposal). >> >> We now have W3C Widgets, Wookie Widgets and Rave Widgets (low/upper >> case?), and I wouldn't be surprised if we get OpenAjax Widgets join the >> party some time soon too. >> Reading the proposal I very quickly got confused and uncertain which one >> was meant or if I might be interpreting/expecting them different. >> Anyway, I don't have an easy solution for this, but this is bound to >> cause much semantic problems and confusion. >> Maybe we should seriously reconsider choosing a new and different name >> for Rave widgets? > > Yes, Scott did try to raise this concern early on ;-) > > From the perspective of Wookie a Widget is either an OpenSocial Gadget or a > W3C Widget. One treats OpenSocial gadgets and W3C widgets identically in > Wookie. That is the method for grabbing an instance and rendering it is the > same regardless of how it is implemented. > >> Question about the proposal and more generally about Wookie/Rave >> integration: >> >> * In you proposal the Admin Widgets would be based on Wookie (alone?), >> but AFAIK those then should (also) be capable to manage Rave widgets in >> general, not just W3C/Wookie Widgets, right? > > As proposed I am talking about Wookie Widgets (which includes OpenSocial > gadgets that the server has been made aware of). > > I propose that Rave uses Wookie for all its management of Rave Widgets. > >> One of the goals of your proposal is that (for Wookie) "The admin >> widgets can be used to create an admin app in any container able to host >> widgets." > > Yes, a widget server admin app, not a Rave admin app or a widgetstore admin > app. > >> Although I find the idea intriguing, I'm doubtful if such admin widgets >> really can be made so generic/independent from Rave that they become >> reusable for other (non-Rave based) container applications. Especially >> as we'll (need to) device a "store model" which is (much) more than just >> the Wookie model... > > There will be Rave specific admin features, such as user management and there > will be widgetstore specific features, like making a widget available. > > My proposal separates these three things out: > > Wookie is the widget server > WidgtetStore is the "app store" of widgets/gadgets > Rave is the "portal" framework > > In this proposal the "admin widgets" are only concerned with administration > of Wookie, e.g. things like: > > - deploy widget/gadget to server > - instantiate widget > - preferences store > - manage whitelist > - manage features > - etc. > > The "widgetstore" would be responsible for things like: > > - searching available widgets > - rendering descriptions of widgets > - rating widgets > - etc. > > Rave is responsible for: > > - user management > - layout managemet > - OpenSocial SPI > - etc. > >> * AFAIK, there are no Wookie admin widgets available yet right now, >> although the team from the UK Open University might want to donate their >> current work in this area. The prominent question is: are they and other >> Wookie users willing to become dependent on Rave for their >> administrative purposes, which also (at least) implies pulling in >> Shindig/OpenSocial into their mix? > > As explained in the proposal, the Wookie team have not voted. I felt it best > to discuss here first. However, the idea has been well received. It is my > belief that if the Rave team are supportive of the idea then a vote will pass. > > Bringing OpenSocial into the mix is not relevant since Wookie already > supports open social. > > The idea of providing the admin interface via widgets has been discussed a > few times, even before Rave was proposed, and has been well received as an > idea. > > Wookie would not be dependant on Rave for its admin application. There would > be a CLI. a REST API and a series of widgets for use in other domains. It's > try that our reference implementation for a GUI would be provided by Rave but > we would not be dependent solely on that implementation. For example, we > already have a lightweight client side "panel" that allows us to render a > number of widgets together, thus providing an alternative admin UI (if the > widgets existed). > > Most importantly, if the Rave community believe this is a good approach then > they Rave community would be contributing to the admin widgets in Wookie. > Wookie loses little (our current admin UI is pretty poor) but potential gains > a great deal. > > >> * The current Rave code donations all already have some level of "store" >> functionality, but based on/targeting the OpenSocial Gadgets. >> I would imagine some of those donations also need to be taken into >> consideration for devising our Rave widgetstore, especially their >> functional and technical needs and then expanded to also cover Wookie. >> I'm not sure if the end result will or can be (only) Wookie based admin >> widgets. Neither am I sure if they will or can be (only) OpenSocial >> Gadgets. More likely outcome IMO is they will become Rave (only) >> specific "widgets". > > I'm not seeing the problem here. Wookie provides support for both Open Social > and W3C Widgets. > > Wookie is not a widgetstore it is a widget server which currently has some > really basic widgetstore features for demonstration purposes. I'm not > proposing using Wookie as the store for Rave on the widget/gadget server. > > There is a separate discussion on the Wookie list about a widget store, but > that is not a part of this proposal. It's too early to tell what will happen > with that. > > Perhaps, because you read both lists, you are reading too much into my > proposal. I am proposing that the widgetstore needs to be a separate > application from both Rave and Wookie so that it can be more widely reused. I > am proposing that the widgetstore provides its admin interface as widgets. > But I'm not proposing Wookie be that store, that's not in our objectives for > Wookie. > > Where the store will be built is a separate issue. > >> * Similar to the question already raised by Gerald concerning OpenSocial >> SPI, how will Wookie manage/access the store meta-data from Rave, for as >> much as Wookie needs that. Seems to me we'll need a Wookie SPI then as >> well, with a specific implementation for the Rave<-Wookie integration. > > Remember Wookie is not a container, it is only a widget/gadget server. Like > OpenSocial it relies on the container to implement any required APIs to > enable the widgets/gadget to run effectively. > > Scott, can you please comment further on this. > >> * On the Wookie dev list I also noticed mentioning of things like >> profiles, users, etc. in the context of the "store" app. Partly >> independent of this proposal (I assume) but don't we need to consider a >> single storage model for a Rave application concerning these things as >> well, being it served by Wookie, Shindig or other "widget" >> container/server. > > See above. This is separate from my proposal here. Wookie does not need an > widgetstore to be useful and, in my opinion, it should not grow to be one. I > see the widget store as a completely separate application that users will use > to find widgets before they are deployed and subsequently instantiated on the > Wookie server. > >> In your proposal Wookie still provides its own persistence layer for >> (among things) user/widget preferences. I wonder if that should be done >> through an SPI layer then as well (like Shindig does) allowing it to be >> delegated to the Rave persistence layer when running on/managed by Rave? > > These two sections were in a single paragraph in your original response. The > storage of preferences against an instance of a widget, at least for me, is > not related to the widgetstore. I therefore assume that these two points are > not connected. > > With respect to an SPI layer proposal I wonder if Scott can comment on this. > As I understand it the W3C widget specification already provides the API for > this. Rave could, if I understand correctly, inject its own persistence > handling into the widgets as they are deployed. This could override the > Wookie provided persistence. > > But why would Rave want to do that? > >> I better stop for now although I can come up with a zillion more >> questions :) > > We need to make sure Scott answers your questions as he is much more > intimately connected to the way Wookie works. I've only got the 10,000 foot > view. > > Ross > >> >> Thanks, >> >> Ate >> >> >> On 05/17/2011 02:38 AM, Ross Gardler wrote: >>> Recently I proposed that Apache Wookie stopped all development on its >>> rather >>> limited admin GUI and instead built its admin GUI using widgets in a Rave >>> application. The proposal has been well received, although we have not >>> yet voted >>> for this major change in strategy. >>> >>> Below is the proposal that we've come up with. Before taking it to a >>> vote over >>> on Wookie I would like to see how the Rave community feel about it. In >>> particular, does the Rave community like the idea of Wookie providing >>> admin >>> widgets that can then be used to develop a W3C Widget and Open Social >>> admin >>> application in Rave. >>> >>> The full details of the proposal are as follows: >>> >>> Wookie is focussed on providing a server based environment for the >>> hosting of Widgets and Gadgets. It provides the necessary >>> infrastructure for clients to request a widget/gadget instance (or a >>> wgt package if appropriate). It also provides a persistence layer so >>> that widgets/gadgets can store preference values. Wookie does not >>> concern itself with the rendering of those widgets/gadgets. >>> >>> Rave is a server that focusses on the provision of user interfaces >>> built from widgets/gadgets. It provides GUI features for end users to >>> configure their portal pages. It does not concern itself with how a >>> widget/gadget is hosted, instead it seeks to leverage Open Social for >>> gadgets and, potentially, Wookie for Widgets. >>> >>> These two applications overlap at the point of the "widget/gadget >>> store". Wookie currently provides a basic UI for the administration of >>> a "store", >>> but also exposes an API to manage this store. Wookie also provides a >>> very basic interface (and functional API) for the creation of >>> widget/gadget instances. >>> >>> In addition some members of the Wookie community are working on a >>> complete widget store. Currently this work is extending Wookie outside >>> of the ASF project. We hope to bring this work into the >>> Wookie project as a separate web application, with its own set of admin >>> widgets. Currently this is a very early stage project and is yet to >>> gather significant momentum. >>> >>> Proposal >>> ======== >>> >>> Wookie will cease to provide a GUI. Instead it will focus on providing >>> a server for the management of widget instances. Administration of this >>> server will be via a REST API. There will be a command line tool and a >>> set of widgets for for administration purposes. >>> >>> The admin widgets can be used to create an admin app in any container >>> able to host widgets. Apache Wookie and Apache Rave will >>> collaborate to provide a reference implementation of an admin GUI >>> using the Wookie admin widgets and the rave widget portal engine. >>> >>> This collaboration would result in something like the following: >>> >>> >>> App Store User Apps >>> /|\ /|\ >>> | | >>> +---------+---------+ >>> | >>> RAVE (GUI Framework) >>> /|\ >>> | >>> +------------+-----------------+ >>> | | >>> | | >>> Admin Widgets User Widgets >>> /|\ /|\ >>> | | >>> +-------------------+ 3rd Party apps >>> | | >>> Wookie (Widget Server) WidgetStore >>> /|\ >>> | >>> Shindig (Open Social Server) >>> >>> Wookie provides the following features: >>> >>> * core features >>> * Parser Widget API >>> * Widget Instances API >>> * Properties API >>> * WhiteList API >>> * Participants API >>> * Flatpack API API >>> * Inter-widget communications >>> * Key API >>> * W3C Widget API (metadata, preferences) >>> * W3C Widget Updates >>> * W3C WARP >>> * JPA Persistence >>> * Proxy >>> >>> * Optional features >>> * Command line admin tool >>> * Admin widgets >>> * Basic example widgets >>> * Scratchpad widgets >>> * JQuery Mobile feature >>> * Wave Feature >>> * oAuth Feature >>> * JCR Persistence >>> * OpenSocial integration >>> >>> The proposed "WidgetStore" provides: >>> >>> * a searchable index plus >>> * search API >>> * tagging API >>> * reviews and ratings API >>> * data sources (W3C metadata, also the Wookie log data) for generating >>> collections and recommendations >>> * Admin widgets >>> >>> Rave provides the necessary GUI framework for building user >>> applications from widgets, the first of which will be the admin >>> application for WOokie and the proposed widet store. >> > > > -- > [email protected] > @rgardler
