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.
