On 11/05/2011 10:21, Scott Wilson wrote:
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?
How do you imagine these optional components being managed? At build
time? At runtime?
The holy grail would be auto-configuration at runtime. That is, if a
widget indicates it requires a non-core feature Wookie tries to find an
implementation, downloads it and installs it (obviously with tight admin
controls).
Currently we require features to be added at compile time. This is not
very satisfactory. Whilst considering what is/is not core we perhaps
ought to think about an extension mechanism too. I'm not suggesting
holding up progress on this proposal until we have an extension
mechanism ready. Buildtime configuration is fine as a starting point,
but having a vision of where we think we are going would be a good idea.
Here's my strawman:
JQuery Mobile is one of many possible frameworks so I'd make this non-core.
As a general guide I would say anything added as a <feature...> in
config.xml should be non-core.
I'd also make the widget examples non-core as they will clutter up a
live install. It's easy enough to add something to the CLI along the
lines of:
wookie installPack widgetSamples
This would get a list of widgets in the "widgetSamples" pack and deploy
them to a running instance.
I have an idea for how this "pack" thing could work. It's just a
convenience for managing groups of widgets from the command line. If we
manage to get runtime deployment of features then these packs could
include appropriate features. I'll implement this in the CLI if we head
in this direction.
(NB this is just the server, not the connectors sub-project)
+1 I don't think any of the connectors should be part of core. They are
for deployment on other platforms.
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.
I have no idea what they are for, so I guess they are not core for me ;-)
Ross
