Given your evaluation I think this will be worthwhile in the looking run. I'm sure we can handle a little upheaval on our apps, it is pre-1.0 after all.
>From a mobile device - forgive errors and terseness On Jun 15, 2012 12:48 PM, "Scott Wilson" <[email protected]> wrote: > Hi everyone, > > Ate suggested a while back the idea of making core Wookie capabilities > work in an "SPI" fashion, i.e. make it possible for the container to > inject its own implementations of core services such as "Preferences" etc., > so these can be integrated with the container backend rather than managed > separately by Wookie. > > However, the way we handle Widget instantiation (widget user sessions, in > effect) in Wookie by using persistent IWidgetInstance beans isn't really > compatible with this approach, as it prevents decoupling things like > Preferences, OAuth tokens, and Widget metadata into discrete services. > > One solution is to adopt the model used by Shindig and inject an encrypted > token into the Widget and use that for subsequent requests. The token is > then unwrapped by Wookie and used to verify the request, and obtain the > parameters to be used in relevant calls (e.g. to get/set preferences, get > the referenced Widget metadata etc). > > I've done some experiments with reusing the OpenSocial Token algorithm > used in Shindig to see how this could work, and it looks like it would be > OK. However, it would mean another big refactoring of the backend. > > PROs: > > - more consistent with Shindig and OpenSocial model > - one less thing to manage as a persistent bean class > - decouples Preferences, Widget metadata, Shared Data, Participants and > oAuth Tokens, making them capable of being wrapped with SPIs > > CONs: > > - yet more refactoring > - will not be backwards compatible > > If we do decide this is a good idea, it may be worth creating a branch for > it as it would touch ~30 classes. > > -S
