On 10/05/2011 19:44, Scott Wilson wrote:
On 10 May 2011, at 16:17, Ross Gardler wrote:
I'd like to propose that some of the code here in Wookie be moved over to
Apache Rave (Incubating). I feel that it is more likely to be maintained and
enhanced there. The code in question is present in Wookie in order to make
Wookie usable, but it is not (IMHO) part of the core objective of Wookie.
If my proposal is accepted it will mean that Wookie would not carry any UI code. Instead
it would focus on providing a server for the management of widget instances. This would
not change the headline goal of Wookie ("Apache Wookie is a Java server application
that allows you to upload and deploy widgets for your applications").
The issue I'd like to discuss in this thread is just where the split between
Rave and Wookie lies. Since Rave is starting from a blank slate it makes sense
to do this here and then discuss our conclusions with the Rave project.
Rationale
=========
Apache Rave (Incubating) [1] is developing an OpenSocial Gadget potrtal-like
framework. It is stated that it is intended to also support W3C Widgets. Scott
and myself are involved with both the Wookie and Rave projects.
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 UI 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 OpenSocial for gadgets and, potentially, Wookie
for Widgets.
These two applications overlap at the point of the "widget/gadget store".
Wookie 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.
Proposal
========
Wookie should deprecate all UI code and provide integration with Rave, thereby
allowing Rave to host W3C Widgets as well as OpenSocial gadgets. Our UI will no
longer be interactive. All administration activities will be carried out via a
command line application, interfacing with Wookie via the REST API. We may
choose to provide text based output from this API, although I would suggest an
XSL transformation of the XML responses from the API would be most appropriate
as this will allow data to be retrieved in multiple formats (CSV, text, HTML
etc.)
Making sure all Wookie's functionality is exposed by REST API should be a
priority - some things (API key management, registering OpenSocial gadgets)
currently aren't and we should fix that.
Second, providing XSLT to make the results of REST API calls more useful is a
good idea.
So, irrespective of the view of the proposal as a whole, I think the above
should be added to Jira anyway (I'll do that soon...)
We should also focus on development of appropriate connectors so that Wookie
widgets/gadgets are presented as part of multiple hosting environments. Our
primary focus will be the Java connector which will be used to provide full
integration with Rave.
If the Rave team so desire they can adopt the API defined by our Java Connector
to allow swappable replacement of widget servers (OpenSocial and Wookie being
the obvious choices at this point).
We should offer all UI code in Wookie to Rave as a starting point for their "Gadget
Store". I imagine that the majority of this code will be re-written by the Rave team
to suit their local needs. However, I also imagine that the work they do will greatly
enhance the work we have done here and, for those people who need a stand alone
administration UI for Wookie we can point them towards Rave.
Thoughts?
I like the idea of making Wookie more lightweight and modular; delegating the
whole concept of an admin client to Rave is an attractive thought from that
perspective. I already largely manage Wookie from the command line anyway -
e.g. dragging and dropping in Widgets to /deploy rather than going through the
web interface. I mostly use the web interface for some interactive debugging
these days.
I'd previously looked into providing Wookie admin functions as widgets (this is
in the scratchapad area). These too could be submitted to Rave.
(Note also I've worked on a prototype using an Apache Solr repository
implementation to support searching and browsing across multiple widget/gadget
providers - this might also be of interest to Rave:
http://iecbolton.jira.com/svn/ITEC/widget_discovery_service/trunk/)
Are you saying that we should remove the UI type files from
"webcontent/*" and move them to rave? (i.e the admin, webmenu folders of
jsps etc). Wookie would then have no front end. Subsequently, things
like settting a context for a widget (i.e. widget type equals "chat") or
setting a white list entry, would then be done from the command line or
through a connector from within wookie? (obviously the connectors need
some more work to do this)
Just so I understand you correctly.
Ross
[1] http://incubator.apache.org/rave
