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.