Hi Scott, this would be great to open a dedicated sub-project under the Wookie's hood. What do we need to take care of? What are the policies for development/code submission and version control? Next week I'll have a meeting with my colleagues, where we will elaborate the first backlog. Should we publish it somewhere?
Best Regards, Olexiy --- Chemnitz University of Technology Department of Computer Science Distributed and Self-organizing Systems Group Straße der Nationen 62 D-09107 Chemnitz Germany E-Mail: [email protected] WWW: http://vsr.informatik.tu-chemnitz.de/people/chudnovskyy Phone: +49 371 531 39146 > -----Original Message----- > From: Scott Wilson [mailto:[email protected]] > Sent: Thursday, July 05, 2012 2:56 PM > To: [email protected] > Subject: Re: Extending widgets towards Inter-Widget-Communication > > > 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 >
