On 05/25/2011 05:48 PM, Ross Gardler wrote:
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.
I wasn't implying anything for current or future Wookie (only) users.
Only that I expect Rave users who need OpenSocial Gadget support probably are
best served natively through Shindig, at least as long Wookie not also fully
implements/supports OpenSocial itself.
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.
Hmm, not sure we're on the same page here.
AFAIK the abstraction layer and logic I expect we implement for Rave to use both
Wookie and Shindig will exist on a very different level than how Wookie
currently integrates (wraps) Shindig. So I think these solutions are very and
possibly too different to easily share code or logic?
Anyway, I was just suggesting the above only from a technical and architectural
perspective. Of course there might be a strong desire within the Wookie
community to retain and further extend OpenSocial Gadget support from within
Wookie, which is certainly fine by me.
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.
I wasn't proposing that at all for Wookie.
My idea is that, for better generalized meta-data management from Rave
perspective, it might be good if Wookie can *also* provide an SPI layer to
integrate on. If so, I'd expect the current Wookie persistence implementation
then also can be wired (by default) on its own SPI, resulting in no fundamental
change for standalone integration purposes.
From Rave perspective this might look like a duplicating development effort,
but we'll have to do the same already anyway for Shindig, so I don't see that as
a real issue actually. On the contrary, it will allow us to generalize the logic
and management of those together instead of having to deal with two unrelated
persistence layers with also are under a different level of control.
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.
To be honest: I'm not convinced yet, as it seems to me both functionally and
technically better for Rave if it can "own" and manage all its meta-data. I can
see the potential benefit for Wookie, but in this case the goals might be (too)
different. But to be fair we haven't decided yet on how the meta-data management
overall (across Shindig, Wookie, Rave) should be partitioned so it might be too
early to draw conclusions.
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.
Yes. As long as it won't limit or hinder the realization of Rave.
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.
IMO that is something we (Rave) very easily should say yes to, as long as it
doesn't require Rave to use these widgets.
And if Rave needs features which cannot be used within or by Wookie, we then
might have to duplicate/rewrite such widgets.
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.
To be clear: I can feel that itch too, so wherever feasible I'd be happy to help
out scratching 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
