On 25/05/2011 10:32, Ate Douma wrote:
On 05/20/2011 12:40 AM, Ross Gardler wrote:
On 19/05/2011 17:14, Ate Douma wrote:
Hi Ross,
I must admit your answers have cleared up several things but confused me
even more on some others ;)
I tend to do that alot ;-)
:)
...
However, in Scott's response to your questions he agrees that it would
make more
sense for Rave to use Shindig directly rather than via Wookie. I defer
to his
far better understanding of both Shindig and Wookie. It's a shame
though, I'd
like to think that the two can become one. I'll leave that goal for a 2.0
version though.
Well, I'm not sure I agree, on this level that is.
As long as the specifications for W3C widgets and OpenSocial are not
(enough) interchangeable, or at least the W3C widgets spec eclipses the
OpenSocial one, I'm not sure why this should be come a critical feature
of Wookie itself. That is, now we have/get Rave who will provide
integration and collaboration between these two (and more) type of
"widgets" on the front-end.
That assumes that everyone who wants to use Wookie to provide W3C Widget
and OpenSocial Gadgets wants to use Rave. This is *not* the case. At
present none of the Wookie users use Rave, but they do host Google
Gadgets. Wookie needs at least a basic support for OpenSocial.
Before Rave it made sense to try to abstract this away on the Wookie
server level, but imo Rave should be able to provide a better and more
extensive solution that ever would "fit" for Wookie alone.
Once we can provide this through Rave I would even go as far as suggest
that Wookie probably better focus solely on the W3C widget spec and
leave the integration and interoperability functionality to Rave...
OK, that's fine. Wookie can always pull the code from Rave into Wookie
if necessary.
I think of these as separate applications because not everything needs
both.
Imagine, for example, a standalone application that ships with a given
set of
Widgets/Gadgets and the appropriate widget/gadget server code. Such an
application would have no need for a widgetstore that allows other
widgets/gadgets to be discovered and instantiated.
Sure. However AFAIK that widget/gadget server still needs the meta-data
management (even if only read only) for those widgets, which also are
under the domain/management of such a widgetstore (repository as I would
call it).
Agreed.
So while you wouldn't need the administration features nor a front-end
application for a widgetstore, I think you still need the backend for it.
That, or in your view the widget/gadget servers keep and maintain their
own backend model, and the widgetstore/repository only interfaces with
it or duplicates/synchronizes them.
My personal view is that widget/gadget servers are or should be (mostly)
lightweight and transient engines which delegate their persistence
management through an SPI to a hosting portal like Rave. That makes them
extremely scalable and reusable while the actual configuration and
(meta) data management stays with and belongs to the concrete solution
domain, e.g. users, security, preferences, appstore/repository, layout,
skins, etc.
This means that for an application to use Wookie as a Widget server it
must also implement the meta-data store, thus duplicating development
effort and making it much harder to use Wookie in existing supported
containers, such as Drupal, Wordpress, Moodle and Elgg. I won't be
proposing that Wookie loses its meta-data engine and defers to Rave for
that.
How about a middle ground in which the meta-data store is a separate
module maintained collaboratively by both Wookie and Rave communities?
This store can be extended by Rave to support any OpenSocial features it
needs that are not required by Wookie.
Really all this proposal boils down to is that Wookie provides a set
of W3C
Widgets that can be used to build an admin application for a W3C
Widget Server.
These W3C Widgets are used within Rave.
Since both Ate and Scott feel it would be better to work directly with
OpenSocial Rave may provide another set of (presumably gadgets) for
administering the the OpenSocial server.
I would expect that the Rave admin widgets would or should abstract away
the differences between W3C, OpenSocial, etc. from a UI management POV.
Agreed.
While certainly these will need to adapt and provide specific management
features depending on each widget/gadget server, IMO Rave should not
(need to) separate these individually if/when the outset goal is to
serve and manage both equally well. But that also might mean these Rave
admin widgets would not be reusable as W3C Widgets externally, only
within (a) Rave instance.
This would be a shame, but possibly unavoidable. we should seek to avoid
it wherever possible.
I'm not sure if limiting our options and capabilities to allow and
support reuse of these admin widgets for within a Wookie only host is in
the best interest of Rave. But I can understand that for Wookie to rely
(only) on Rave for its admin *UI* also might be limiting.
So I'm really not sure how we should tackle this.
In my proposal to Wookie we will be maintaining admin widgets for reuse
in containers like Rave. There is no need for Rave to limit itself to
only these widgets. I'm not proposing that, I am only proposing that
Rave use (and contribute) to these widgets wherever it makes sense.
I would hope that in the majority of
cases the W3C Widgets can be used directly or extended to support
OpenSocial
containers too.
I imagine the same model for the widgetstore, that is a separate server
application that provides an API and suitable widgets/gadgets for
interacting
with the "catalogue" of widgets.
I agree it might be a separate application (an/or directly integratable
in *a* Rave portal instance if so desired).
Right now though I see this as a "native function of Rave and belong up
in the Rave box" (quoting Matt here from a different thread).
OK. It seems like a duplication of effort to me. However, I recognise
that's because I want the freedom to use the widgetstore code elsewhere.
If that itch gets strong enough then I'll just have to scratch it.
IMO our first objectives for Rave should be to get a working and usable
solution for the current contributers such that they can start
converting to it ASAP.
Good point.
Ross
