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.
