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.
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?
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?
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."
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...
* 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?
* 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".
* 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.
* 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.
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?
I better stop for now although I can come up with a zillion more questions :)
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.
