On 4 May 2011, at 22:36, Franklin, Matthew B. wrote:
> As we start to implement more of the OpenSocial constructs within the
> container, I think it is probably appropriate to begin discussing the
> impact of supporting multiple widget types on the model.
>
> Anyone have a strategy in mind?
OpenSocial/Shindig requires a lot more plumbing than W3C Widgets/Wookie - the
only hook really needed for Wookie is to get the spec for rendering a widget
(title, height, width, iframe src) by calling the Wookie REST API and for
telling it who's looking at it (participant id/name/icon - same as Wave). There
are no data APIs or RPC hooks or anything like that needed, though we probably
would want to do something to support inter-widget communication (extending
Wookie to support the Shindig pubsub feature might be the easiest solution
there).
I'm assuming that the basic idea is that the Rave Widget model class is used to
persist sufficient metadata about the widget (of whatever type) so that it can
be rendered by the layout engine at runtime for a particular user? In which
case there has to be some sort of service method (WidgetService?) that each
adapter for a widget type needs to implement - did you have some ideas about
what that should look like? I guess I'm imagining something along the lines of:
public URL renderWidget(User user, RegionWidget regionWidget){
}
Or is it a bit more complex than that..?
At the site level we also need some sort of palette or menu system for adding
widgets based on what's available in available containers. The actual metadata
is mostly quite similar - titles, authors, icons etc. Wookie exposes metadata
on all available widget in its REST API. Some user stories for how we envisage
users discovering and adding widgets/gadgets to the workspace would be useful
here.
>
> -Matt
>
> On 5/4/11 5:23 PM, "Matt Franklin (JIRA)" <[email protected]> wrote:
>
>> Implement User Prefs
>> --------------------
>>
>> Key: RAVE-27
>> URL: https://issues.apache.org/jira/browse/RAVE-27
>> Project: Rave
>> Issue Type: Technical task
>> Reporter: Matt Franklin
>>
>>
>> Implement persistence of user prefs, container services and RPC callbacks
>>
>> --
>> This message is automatically generated by JIRA.
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
