You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wookie.apache.org by Scott Wilson <sc...@gmail.com> on 2012/05/28 23:12:04 UTC

SPIs (was Re: Modularization)

(Moving this over to the Wookie-dev list)

On 28 May 2012, at 20:33, Ate Douma wrote:

> On 05/25/2012 10:54 PM, Chris Geer wrote:

>> 2) I know we want to support multiple UI layers (OpenSocial, W3C...) but
>> OpenSocial is the only one so far that defines a backend data structure as
>> far as I know.
> I think OpenSocial doesn't even define a backend data structure, Shindig does.
> And the same goes for W3C Widgets, while Wookie does have a back-end model.
> The real difference IMO is that Shindig provides an abstract model/SPI while Wookie does not. Yet...
> 
> What I've suggested before is the option to modularize Wookie a bit further and see if we can come up with a separate backend model/SPI for Wookie as well.
> Of course that is a discussion for the Wookie project itself, but IMO it is something which would benefit both Wookie and help with a much better integration and support within Rave.

I think its a good idea - Wookie could run in almost pure processing mode with very little persistence beyond the (largely static) widget metadata with the Preference and SharedContext handling delegated using SPIs.

We'd still need a default implementation for standalone Wookie deployment, but even then some pluggability would be a good thing - for example, for better performance I sometimes want to set up the Wave API feature using a Node.js/WebSockets/Redis backend rather than the default JPA/DWR implementation. 

The relevant interfaces are IWidgetAPI and IWaveAPI; I guess we would need to provide a means of injecting implementations of these.