On 5 Jul 2012, at 13:20, Ross Gardler wrote: > On 5 July 2012 13:07, Olexiy Chudnovskyy > <[email protected]> wrote: >> Hi Scott & Ross, >> >> here is the source code of our prototype and a tutorial to get it running: >> >> http://vsr.informatik.tu-chemnitz.de/demo/iwc-extension/apache-wookie-iwc-0. >> 10.0-incubating-standalone.zip >> http://vsr.informatik.tu-chemnitz.de/demo/iwc-extension/tutorial.pdf > > Thanks. I'll take a look ASAP, but since I'm about to hit the road for > a couple of weeks it won't be soon. > >> I like Scott's idea on "IWC Enchancer" add-on, which is completely decoupled >> from a concrete widget container instance. This is definitely a cleaner >> solution. >> Another scenario is, however, extension of an already deployed widget. Or do >> you think this situation is rather unusual? > > There are at least three ways of thinking about this scenario: > > - have a standalone enhancer that understands the Wookie API - request > the .wgt file, enhance, re-submit it > > - embed the enhancer within Wookie for tight integration > > These two approaches are not necessarily mutually exclusive. If the > enhancer is capable of working stand-alone then it can also be > included in a Wookie distribution and installed without user > intervention, along with a suitable interface for accessing it. > However, bear in mind that the admin UI in Wookie has been removed. > The current goal of Wookie is to ensure the API is fully functional so > that third parties can build admin UIs specific to their needs. We > have discussed the idea of providing a set of admin widgets but nobody > currently has that high enough on their task list. > > Furthermore, by decoupling the enhancer from Wookie you are opening up > the potential for the enhancer to be extended to work with other > gadget/widget specs if that becomes an strong enough itch for someone. > > This would suggest to me that the standalone system accessing Wookie > through the API would be the best approach. If the interface can > become a widget then all the better (note Scott did some > experimentation with admin widgets). > > However, by suggesting this path I am not intending to imply we don't > want it here in the Wookie project. I'd be +1 to making it a > subproject here. If it ever grows up to work with other kinds of > gadgets then it could become a TLP in its own right, but while it > focusses on Wookie APIs and widgets it makes sense for it to be a > sub-project.
+1 I think the enhancer would make a good subproject, I like the idea of potentially supporting other widget types, plus it would be good to have different options for which IWC solution to enhance the widget with (OpenAjax, Role/XMPP, PostMessage etc). Currently we have some sub-projects in the Wookie trunk, and these are built and deployed in the standard distribution - would this work for the enhancer too, or should we create a directory at the top level, e.g. /incubator/wookie/enhancer/trunk ? S > > Ross
