On 11 May 2011, at 15:37, Scott Wilson wrote: > > 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. +1 sounds good, I like the idea of "packs". >>> >>>> (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 >> >
