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
