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. Ross
