Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
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.