Hi Ross, thanks for the extensive answer! Together with my colleagues we will start working on a separate application using Wookie API and relying on OpenAjax Pub/Sub implementation to make it a Wookie sub-project in the first line.
We also thought on possible extensions towards other widget specs. The difficulty we see here is the lack of a standardized IWC framework. OpenAjax seems to be a common solution, but IWC-Enchancer cannot know in which other dashboards with which IWC-facilities the widgets will be running in. However, a possible solution could be to let user choose which Pub/Sub framework should be used before the enhanced widget gets exported. Best Regards, Olexiy E-Mail: [email protected] Phone: +49 371 531 39146 Chemnitz University of Technology Department of Computer Science Distributed and Self-organizing Systems Group Straße der Nationen 62 D-09107 Chemnitz Germany > -----Original Message----- > From: Ross Gardler [mailto:[email protected]] > Sent: Thursday, July 05, 2012 2:20 PM > To: [email protected] > Subject: Re: Extending widgets towards Inter-Widget-Communication > > 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
