incubator-wookie-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Wilson <scott.bradley.wil...@gmail.com>
Subject Re: [PROPOSAL] Wookie gadget "store" moved to Rave?
Date Tue, 10 May 2011 18:44:13 GMT
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/)

> 
> Ross
> [1] http://incubator.apache.org/rave


Mime
View raw message