On 11 May 2011, at 12:29, Scott Wilson wrote: > On 11 May 2011, at 12:08, Ross Gardler wrote: > >> 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. > > Yes, for feature installs I'd really like to do something better than what we > have now. There really is no reason these have to be Java classes, they could > just as easily be XML config files loaded at runtime; they were patterned > after the Wave feature extension which had a lot more server-side custom > code, but that may be better treated as the exception rather than the > template. > > So a future model could be feature packages with: > > /myfeature > feature.xml > (various js and css files) > > ... where "feature.xml" is something like: > > <feature> > <name>http://jquerymobile.com</name> > <script src="jquery-1.5.min.js"/> > <script src="jquery.mobile-1.0a4-patched.min.js"/> > <stylesheet src="jquery.mobile-1.0a4.min.css"/> > </feature> > > (which is quite similar to how Shindig manages features)
As this is something I've been meaning to do for ages, I added a ticket for it and went ahead and implemented this. Its quite a bit of refactoring (mostly deletions) but it doesn't look like it breaks any tests. The new approach loads Features on start by inspecting the /features folder of the local installation and then creating Feature objects for each valid feature.xml file. It holds these in a static List rather than saving them in the database (its only ever going to be a few small objects and doesn't need any query support). This could be extended relatively easily to include a folder watcher to dynamically install features (similar to widgets) or to dynamically discover and install features if they're needed for a widget (the UC Ross mentioned above) as Feature no longer require any compilation steps. I'm ready to commit this - I just wanted to give everyone a chance to comment/object before I went ahead. > >> >>> 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 >
