Just kicking off a new thread here, as its something we need to think about for future direction.
The core purpose of Wookie is to be a W3C Widget server, however it also does some "other stuff". At the moment, we build the whole project in one go. However, it may be useful to have non-core modules as optional builds rather than core functionality. Steve mentions Wave as one example. The Wave feature is a very nice one, but isn't a core W3C Widget feature. So this might be factored out into an optional module (you could use either the Java/DWR or NodeJS implementations) Another one is JCR support. Currently Wookie is built with both JPA and JCR persistence - should JCR be an optional, pluggable module rather than built-in? Here's my strawman: Core ==== Parser Widget API Widget Instances API Properties API WhiteList API Participants API Flatpack API API Key API (todo) W3C Widget API (metadata, preferences) W3C Widget Updates W3C WARP JPA Persistence Proxy JQuery Mobile feature Basic example widgets Optional ======= Wave Feature oAuth Feature (todo) JCR Persistence OpenSocial integration Scratchpad widgets (NB this is just the server, not the connectors sub-project) I'm not sure about "services" (effectively, tags) as to whether this really is Wookie core functionality or something a "widget store" like Rave's would add on top, e.g. user-generated tagging. S On 11 May 2011, at 09:25, Steve Lee wrote: > >> Wookie is focussed on providing a server based environment for the hosting >> of Widgets and Gadgets. It provides the necessary infrastructure for clients >> to request a widget/gadget instance (or a wgt package if appropriate). It >> also provides a persistence layer so that widgets/gadgets can store >> preference values. Wookie does not concern itself with the rendering of >> those widgets/gadgets. > > I may be getting confused but doesn't Wookie also implement Wave APIs > - do these really belong there as well? But that's another > discussion....
