Hi Ross,
I must admit your answers have cleared up several things but confused me even
more on some others ;)
Follow up questions below.
Regards,
Ate
On 05/17/2011 04:42 PM, 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.
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.
I know. But that doesn't help making it less confusing semantically :)
So, should we discuss if we should or need a more differentiating term for our
Rave widgets, or are you suggesting to drop the notion of Rave widgets all
together and just use Wookie widgets as primary concept ...?
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.
OK, that much is clear now.
I'm certainly open to the idea, but what I'm not sure of is if this might impose
limitations to dealing with OpenSocial Gadgets related administration and
management. In a Rave portal environment (so not any other container), I expect
we'll use Shindig directly to render OpenSocial Gadgets, not via Wookie.
It might be fine to use (only) Wookie for implementing our admin widgets, but
please note that Wookie does have some limitations for rendering OpenSocial
Gadgets. So possibly this might pose restrictions in the context of managing
OpenSocial Gadgets, e.g. like showing a Gadget preview or dealing with "People"
related meta-data during the administration?
The thing really unclear yet is who "owns" and manages the data.
My current view is very much like what Matt said on the other discussion
concerning the OpenSocial SPI implementation: Rave manages the core data, which
includes security, people, widgets (store *and* instances?), pages, etc. and
this then gets re-exposed to the rendering engines, e.g. through some SPI
integration layer.
Can you explain how this works with your proposal, to use Wookie for all admin
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:
Here you've got me confused.
I think earlier you said you want to use Wookie for the administration of all
Rave Widgets, but now you say only administration of Wookie (widgets), right?
- deploy widget/gadget to server
- instantiate widget
- preferences store
- manage whitelist
- manage features
- etc.
So these are Wookie *specific* administration widgets AFAIK, not dealing with
OpenSocial Gadgets which are not served by Wookie, but might be served natively
by Shindig?
The "widgetstore" would be responsible for things like:
- searching available widgets
- rendering descriptions of widgets
- rating widgets
- etc.
The widgetstore however should cover all Rave widgets, Widgets/Gadgets to be
rendered by Wookie and also Gadgets to be rendered (directly) by Shindig.
Rave is responsible for:
- user management
- layout managemet
- OpenSocial SPI
- etc.
Important IMO to mention here is page management, which will require referencing
Rave widgets (from the store).
* 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.
True, but it doesn't depend on it unless you need it.
Adding a Rave based widgetstore then might force you into it if we want or need
to depend also on Shindig for the widgetstore.
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.
OK... So does that mean the widgetstore meta-data is "owned" by Wookie?
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.
Well, the OpenSocial support is only up to a certain point AFAIK.
Reference: http://wookie.staging.apache.org/wookie/docs/shindig.html
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.
OK, but who is managing/owning the store then, if its neither Rave nor Wookie?
This seems to me the key question to answer first.
As I said above: I'm still pretty confused ;)
* 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.
Sounds more like a shop then?
My interpretation so far was that this was more than just that. Within a
container/portal there will be many references to the (store/shop) meta-data of
a widget/gadget instance. So AFAIK there will be a need for an integration layer
between the container/portal and the store.
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.
The management and storage of preferences might be unrelated to the store, but
the reference of the widget/gadget instance AFAIK cannot.
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?
See above: because I assume there will be a need to integrate and relate
instances with their meta-data managed in the store.
Maybe all this really is mostly a semantic confusion though.
To me the term "store" in your proposal sounds like a "shop" whereas I expect
we'll need more a "repository" like store.
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.
Same here, so we both might be talking through clouds ;)
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.
