You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wookie.apache.org by Olexiy Chudnovskyy <ol...@informatik.tu-chemnitz.de> on 2012/07/05 14:07:21 UTC
RE: Extending widgets towards Inter-Widget-Communication
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
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?
Best Regards,
Olexiy
E-Mail: olexiy.chudnovskyy@informatik.tu-chemnitz.de
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: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
> Sent: Friday, June 29, 2012 5:44 PM
> To: wookie-dev@incubator.apache.org
> Subject: Re: Extending widgets towards Inter-Widget-Communication
>
> On 29 Jun 2012, at 13:46, Olexiy Chudnovskyy wrote:
>
> > Hi Ross,
> >
> > thanks for your fast reply.
> >
> >> What I wanted to say is that your approach looks really good. I liked
> >> what
> > I
> >> saw in the video from a concept point of view. I really like the
> > simplicity of
> >> wiring widgets together. It looked potentially very powerful. I'd
> >> love to
> > see it
> >> applied in a more complex environment.
> >> Getting the code here would be a good way of encouraging that.
> >
> > I will put the source code online and publish the link here.
> >
> >>
> >> A couple of things I noticed. Most significantly it looked like your
> >> demo
> > is built
> >> on a pretty old version of Wookie (perhaps 0.8?). It probably
> >> wouldn't
> > take
> >> much to bring it all up to date, but we need to be aware of this.
> >
> > The current prototype was ported to Wookie 0.10 (the screencast is a
> > little older). It wasn't important for us at that moment as we just
> > wanted to demonstrate the idea. Also we don't utilize OpenAjax-Event
> > Bus of Wookie yet, but use our own quick & dirty implementation.
> > However, it is planned to switch to Wookie's IWC implementation.
> >
> >>
> >> This solution wouldn't work outside a browser instance would it? That
> >> is I couldn't have a map widget on Foo's page respond to the changes on
> Bar's.
> >>
> >> Would it work across browser tabs?
> >
> > If the Wookie-Event Bus implementation would allow it - than yes, as
> > widgets do nothing else then sending messages to the public event bus.
>
> In Rave using the OpenAjax implementation of IWC it wouldn't as the scope
> of that is the browser window - OpenAjax relays the messages from child
> iFrames to the container and then to its registered children.
>
> However, if the ROLE implementation is ported to Rave, then that uses
> XMPP and server-side relaying, so that ought to work.
>
> As long as the messaging implementation works using the same API (i.e.
> hub.publish(topic,message); hub.subscribe(topic, callback)) it should also
be
> portable between implementations.
>
> >
> >>
> >> In general, speaking purely as a potential user rather than a
> >> currently
> > active
> >> Wookie developer, I would like to see this integrated into Wookie and
> >> am happy to help in any way I can.
> >
> > Thanks, every feedback and report on experience with the system would
> > be helpful!
>
> Its a really nice solution for interactive widget development; maybe
rather
> than extending the core Wookie server perhaps it could be an add-on
> application for use by widget developers? So something like:
>
> - user opens the "IWC Enchancer" application
> - user selects a widget src folder
> - "IWC Enchancer" application publishes widget to local Wookie server
> - user interacts with widget; "IWC Enchancer" application prompts user to
> annotate iwc events
> - "IWC Enchancer" application save changes to widget src folder, and re-
> deploys updated widget to Wookie
>
> What do you think?
>
> >
> > Best Regards,
> > Olexiy
> >
> >
> >>
> >> On 29 June 2012 12:58, Olexiy Chudnovskyy
> >> <ol...@informatik.tu-chemnitz.de> wrote:
> >>> Hi all,
> >>>
> >>>
> >>>
> >>> my name is Olexiy Chudnovskyy, im a PhD student of Chemnitz
> >>> University of Technology. Together with other universities and
> >>> industrial partners we use/contribute to Wookie in course of the
> >>> European Research Project OMELETTE. Currently, our research focuses
> >>> on inter-widget communication facilities, which were introduced also
> >>> in
> >> Wookie since 0.10 release.
> >>>
> >>>
> >>>
> >>> I wanted to share with you an idea of enriching existing stand-alone
> >>> widgets with inter-widget communication functionality. The goal is
> >>> to make already deployed widgets talking to each other without
> >>> manual intervention into widget internals. We have published a paper
> >>> on the approach and built a first simple prototype to demonstrate
> >>> how its
> >> working:
> >>>
> >>>
> >>>
> >>> <http://vsr.informatik.tu-chemnitz.de/demo/iwc-extension>
> >>> http://vsr.informatik.tu-chemnitz.de/demo/iwc-extension
> >>>
> >>>
> >>>
> >>> It would be interesting to find out, what do you think about the idea.
> >>> Do you find it useful? Is this way of extending widgets is
> >>> understandable for end users?
> >>>
> >>>
> >>>
> >>> I would be happy to get some feedback from you!
> >>>
> >>>
> >>>
> >>> Best Regards,
> >>>
> >>> Olexiy
> >>>
> >>>
> >>>
> >>> E-Mail: <ma...@informatik.tu-chemnitz.de>
> >>> olexiy.chudnovskyy@informatik.tu-chemnitz.de
> >>>
> >>> 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
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> Ross Gardler (@rgardler)
> >> Programme Leader (Open Development)
> >> OpenDirective http://opendirective.com
> >
> >
>
Re: Extending widgets towards Inter-Widget-Communication
Posted by Ross Gardler <rg...@opendirective.com>.
On 5 July 2012 13:44, Olexiy Chudnovskyy
<ol...@informatik.tu-chemnitz.de> wrote:
> 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.
That's great, but do understand I'm only one voice (and a reasonably
inactive one too) so it's not a given that others will agree it makes
sense to bring it here as a sub-project. That being said if no-one
objects you can assume "lazy consensus" and we can proceed. Even if
people decide this is not a suitable home for some reason I think your
work in separating it out will be time well spent and we'll find a
good home and some of us will surely use your code.
Ross
RE: Extending widgets towards Inter-Widget-Communication
Posted by Olexiy Chudnovskyy <ol...@informatik.tu-chemnitz.de>.
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: olexiy.chudnovskyy@informatik.tu-chemnitz.de
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:rgardler@opendirective.com]
> Sent: Thursday, July 05, 2012 2:20 PM
> To: wookie-dev@incubator.apache.org
> Subject: Re: Extending widgets towards Inter-Widget-Communication
>
> On 5 July 2012 13:07, Olexiy Chudnovskyy
> <ol...@informatik.tu-chemnitz.de> 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
Re: Extending widgets towards Inter-Widget-Communication
Posted by Scott Wilson <sc...@gmail.com>.
On 9 Jul 2012, at 09:46, Olexiy Chudnovskyy wrote:
> Hi Scott,
>
>>
>> There are also a couple of W3C widgets on the ROLE widgetstore:
>>
>> http://www.role-widgetstore.eu/
>
> Thanks, there seems to be many widgets available! As far as I see, many of
> them are OpenSocial. However, we could take them in IWC-Enchancer into
> account. I wonder - is there any IWC spec in OpenSocial standard? Can W3C
> and OpenSocial widgets communicate within one single Rave dashboard
Both OpenSocial and W3C Widgets in Rave can use OpenAjax Hub for IWC - and yes they can communicate with each other.
>
>>
>> And of course you can do a search for .wgt files, e.g. on Filecrop - that
> mostly
>> turns up a lot of clock and weather widgets for different phones :)
>>
>
> Thanks, good to know!
>
>> I had some code for converting Chrome Installed Apps into Widgets; its
>> probably outdated now, but its on Github if he wants to reuse it:
>>
>> http://scottbw.wordpress.com/2011/02/17/converting-chrome-installed-
>> web-apps-into-w3c-widgets/
>>
>
> We'll have a look, thanks! As soon as our conversion tool is ready, we will
> report on that.
>
> Best Regards,
> Olexiy
>
RE: Extending widgets towards Inter-Widget-Communication
Posted by Olexiy Chudnovskyy <ol...@informatik.tu-chemnitz.de>.
Hi Scott,
>
> There are also a couple of W3C widgets on the ROLE widgetstore:
>
> http://www.role-widgetstore.eu/
Thanks, there seems to be many widgets available! As far as I see, many of
them are OpenSocial. However, we could take them in IWC-Enchancer into
account. I wonder - is there any IWC spec in OpenSocial standard? Can W3C
and OpenSocial widgets communicate within one single Rave dashboard?
>
> And of course you can do a search for .wgt files, e.g. on Filecrop - that
mostly
> turns up a lot of clock and weather widgets for different phones :)
>
Thanks, good to know!
> I had some code for converting Chrome Installed Apps into Widgets; its
> probably outdated now, but its on Github if he wants to reuse it:
>
> http://scottbw.wordpress.com/2011/02/17/converting-chrome-installed-
> web-apps-into-w3c-widgets/
>
We'll have a look, thanks! As soon as our conversion tool is ready, we will
report on that.
Best Regards,
Olexiy
Re: Extending widgets towards Inter-Widget-Communication
Posted by Scott Wilson <sc...@gmail.com>.
On 9 Jul 2012, at 09:08, Olexiy Chudnovskyy wrote:
> Hi Scott,
>
> yes, we've already tried Opera widgets - unfortunately many of them are
> broken.
Well, a lot of them use Opera's own earlier spec rather than W3C - which mostly just looks like a broken wgt.
There are also a couple of W3C widgets on the ROLE widgetstore:
http://www.role-widgetstore.eu/
And of course you can do a search for .wgt files, e.g. on Filecrop - that mostly turns up a lot of clock and weather widgets for different phones :)
Part of the issue is that most of the other implementations tend to rebrand W3C widgets - e.g. as "samsung apps", "blackberry widgets", "vodafone widgets" etc., and then only allow download via their services or devices.
> We haven't found any W3C repository - the only idea we came up with
> - converting iGoogle, Netvibes, Opera to W3C to create some initial
> database. A student of us is working on a conversion tool, tackling
> peculiarities of different formats. Currently he is evaluating which
> percentage of Netvibes / iGoogle widgets the tool will manage to convert.
> First results were pretty promising.
Thats a great idea.
I had some code for converting Chrome Installed Apps into Widgets; its probably outdated now, but its on Github if he wants to reuse it:
http://scottbw.wordpress.com/2011/02/17/converting-chrome-installed-web-apps-into-w3c-widgets/
>
> 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: olexiy.chudnovskyy@informatik.tu-chemnitz.de
> WWW: http://vsr.informatik.tu-chemnitz.de/people/chudnovskyy
> Phone: +49 371 531 39146
>
>
>> -----Original Message-----
>> From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
>> Sent: Monday, July 09, 2012 9:59 AM
>> To: wookie-dev@incubator.apache.org
>> Subject: Re: Extending widgets towards Inter-Widget-Communication
>>
>>
>> On 9 Jul 2012, at 08:50, Olexiy Chudnovskyy wrote:
>>
>>> Hi Ross,
>>>
>>>>
>>>> I suspect the best way to proceed is to start out extracting your
>>>> code
>>> into the
>>>> stand-alone project we've discussed. It would be best to do that in
>>>> stages contributing patches directly to Wookie as you go. This will
>>>> enable us to evaluate individual contributors patches and recognise
>>>> individual merit as appropriate. It will make things a little slower
>>>> to start with as you will
>>> need
>>>> someone here to submit your patches to version control. However,
>>>> since nobody here is likely to work on it in the short term this
>>>> shouldn't pose
>>> much
>>>> of a problem.
>>>> The advantage is that we would be able to give commit rights in
>>> recognition
>>>> of the work being done during the porting.
>>>>
>>>
>>> I think this is the best option. As soon as we have IWC-Enchancer
>>> extracted out of Wookie I will come back to you.
>>>
>>> One other question - do you know if and where we can find some
>>> real-life W3C widgets to experiment with? Are there any widget
>>> repositories existing on the Web or being developed in other projects
>> (beside OMELETTE)?
>>
>> Opera have some:
>>
>> http://widgets.opera.com/
>>
>> .. though not all are W3C-compliant
>>
>> A lot of the other widgets around seem to be locked into mobile
>> operator/handset vendor app stores e.g. Vodafone, Samsung rather than
>> publicly downloadable via the browser
>>
>>
>>>
>>> Best Regards,
>>> Olexiy
>>>
>>
>
>
RE: Extending widgets towards Inter-Widget-Communication
Posted by Olexiy Chudnovskyy <ol...@informatik.tu-chemnitz.de>.
Hi Scott,
yes, we've already tried Opera widgets - unfortunately many of them are
broken. We haven't found any W3C repository - the only idea we came up with
- converting iGoogle, Netvibes, Opera to W3C to create some initial
database. A student of us is working on a conversion tool, tackling
peculiarities of different formats. Currently he is evaluating which
percentage of Netvibes / iGoogle widgets the tool will manage to convert.
First results were pretty promising.
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: olexiy.chudnovskyy@informatik.tu-chemnitz.de
WWW: http://vsr.informatik.tu-chemnitz.de/people/chudnovskyy
Phone: +49 371 531 39146
> -----Original Message-----
> From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
> Sent: Monday, July 09, 2012 9:59 AM
> To: wookie-dev@incubator.apache.org
> Subject: Re: Extending widgets towards Inter-Widget-Communication
>
>
> On 9 Jul 2012, at 08:50, Olexiy Chudnovskyy wrote:
>
> > Hi Ross,
> >
> >>
> >> I suspect the best way to proceed is to start out extracting your
> >> code
> > into the
> >> stand-alone project we've discussed. It would be best to do that in
> >> stages contributing patches directly to Wookie as you go. This will
> >> enable us to evaluate individual contributors patches and recognise
> >> individual merit as appropriate. It will make things a little slower
> >> to start with as you will
> > need
> >> someone here to submit your patches to version control. However,
> >> since nobody here is likely to work on it in the short term this
> >> shouldn't pose
> > much
> >> of a problem.
> >> The advantage is that we would be able to give commit rights in
> > recognition
> >> of the work being done during the porting.
> >>
> >
> > I think this is the best option. As soon as we have IWC-Enchancer
> > extracted out of Wookie I will come back to you.
> >
> > One other question - do you know if and where we can find some
> > real-life W3C widgets to experiment with? Are there any widget
> > repositories existing on the Web or being developed in other projects
> (beside OMELETTE)?
>
> Opera have some:
>
> http://widgets.opera.com/
>
> .. though not all are W3C-compliant
>
> A lot of the other widgets around seem to be locked into mobile
> operator/handset vendor app stores e.g. Vodafone, Samsung rather than
> publicly downloadable via the browser
>
>
> >
> > Best Regards,
> > Olexiy
> >
>
Re: Extending widgets towards Inter-Widget-Communication
Posted by Scott Wilson <sc...@gmail.com>.
On 9 Jul 2012, at 08:50, Olexiy Chudnovskyy wrote:
> Hi Ross,
>
>>
>> I suspect the best way to proceed is to start out extracting your code
> into the
>> stand-alone project we've discussed. It would be best to do that in stages
>> contributing patches directly to Wookie as you go. This will enable us to
>> evaluate individual contributors patches and recognise individual merit as
>> appropriate. It will make things a little slower to start with as you will
> need
>> someone here to submit your patches to version control. However, since
>> nobody here is likely to work on it in the short term this shouldn't pose
> much
>> of a problem.
>> The advantage is that we would be able to give commit rights in
> recognition
>> of the work being done during the porting.
>>
>
> I think this is the best option. As soon as we have IWC-Enchancer extracted
> out of Wookie I will come back to you.
>
> One other question - do you know if and where we can find some real-life W3C
> widgets to experiment with? Are there any widget repositories existing on
> the Web or being developed in other projects (beside OMELETTE)?
Opera have some:
http://widgets.opera.com/
.. though not all are W3C-compliant
A lot of the other widgets around seem to be locked into mobile operator/handset vendor app stores e.g. Vodafone, Samsung rather than publicly downloadable via the browser
>
> Best Regards,
> Olexiy
>
RE: Extending widgets towards Inter-Widget-Communication
Posted by Olexiy Chudnovskyy <ol...@informatik.tu-chemnitz.de>.
Hi Ross,
>
> I suspect the best way to proceed is to start out extracting your code
into the
> stand-alone project we've discussed. It would be best to do that in stages
> contributing patches directly to Wookie as you go. This will enable us to
> evaluate individual contributors patches and recognise individual merit as
> appropriate. It will make things a little slower to start with as you will
need
> someone here to submit your patches to version control. However, since
> nobody here is likely to work on it in the short term this shouldn't pose
much
> of a problem.
> The advantage is that we would be able to give commit rights in
recognition
> of the work being done during the porting.
>
I think this is the best option. As soon as we have IWC-Enchancer extracted
out of Wookie I will come back to you.
One other question - do you know if and where we can find some real-life W3C
widgets to experiment with? Are there any widget repositories existing on
the Web or being developed in other projects (beside OMELETTE)?
Best Regards,
Olexiy
Re: Extending widgets towards Inter-Widget-Communication
Posted by Ross Gardler <rg...@opendirective.com>.
It's great to hear you want to work with is on this.
Apache projects work on a meritocratic basis. If someone contributes
to get commit rights.
Before someone gets commit rights they need to submit patches for
review. This is done through the issue tracker. Once the number of
patches or even a single significant patch is accepted by the project
contributors may be invited to become committers. This process is
called review then commit (RTC). Since this review process can be
time-consuming we tried to make people committers earlier rather than
later.
Once they are committers they can make changes directly in the version
control system. Such changes are sent to the commit mailing list where
other committers will review them. This process is called commit then
review (CTR). Committers need to submit an Individual Contributer a
License Agreement (ICLA).
With significant contributions that involve many developers we need to
have a software grant and make all developers committers upon initial
contribution. I doubt that this contribution will require this.
However, your mail implies that there are multiple developers involved
with this contribution.
I suspect the best way to proceed is to start out extracting your code
into the stand-alone project we've discussed. It would be best to do
that in stages contributing patches directly to Wookie as you go. This
will enable us to evaluate individual contributors patches and
recognise individual merit as appropriate. It will make things a
little slower to start with as you will need someone here to submit
your patches to version control. However, since nobody here is likely
to work on it in the short term this shouldn't pose much of a problem.
The advantage is that we would be able to give commit rights in
recognition of the work being done during the porting.
Alternatively, you could do this work in somewhere like Apache-extras
(an area within Google code). This would allow you to give write
access to your full developer team early and would enable the Eookie
team to review each contributors activity there. However, merit in an
Apache project cannot be earned through contributions to a non-Apache
project. This means that it would be slower for your team to get
commit access here.
What is less than ideal is for you to submit a large amount of
completed code with a request to make a number of, to us unknown,
people as committers.
Which is the best approach for you depends on your team. Trying to
work here through patches will slow your initial work but ultimately
get you commit access here more quickly, which will enable you to
create a tighter integration with Wookie without having to depend on
existing committers.
Ross
On 6 July 2012 09:30, Olexiy Chudnovskyy
<ol...@informatik.tu-chemnitz.de> wrote:
> 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: olexiy.chudnovskyy@informatik.tu-chemnitz.de
> WWW: http://vsr.informatik.tu-chemnitz.de/people/chudnovskyy
> Phone: +49 371 531 39146
>
>> -----Original Message-----
>> From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
>> Sent: Thursday, July 05, 2012 2:56 PM
>> To: wookie-dev@incubator.apache.org
>> 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
>> > <ol...@informatik.tu-chemnitz.de> 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
>>
>
>
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com
RE: Extending widgets towards Inter-Widget-Communication
Posted by Olexiy Chudnovskyy <ol...@informatik.tu-chemnitz.de>.
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: olexiy.chudnovskyy@informatik.tu-chemnitz.de
WWW: http://vsr.informatik.tu-chemnitz.de/people/chudnovskyy
Phone: +49 371 531 39146
> -----Original Message-----
> From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
> Sent: Thursday, July 05, 2012 2:56 PM
> To: wookie-dev@incubator.apache.org
> 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
> > <ol...@informatik.tu-chemnitz.de> 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
>
Re: Extending widgets towards Inter-Widget-Communication
Posted by Scott Wilson <sc...@gmail.com>.
On 5 Jul 2012, at 13:20, Ross Gardler wrote:
> On 5 July 2012 13:07, Olexiy Chudnovskyy
> <ol...@informatik.tu-chemnitz.de> 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
Re: Extending widgets towards Inter-Widget-Communication
Posted by Ross Gardler <rg...@opendirective.com>.
On 5 July 2012 13:07, Olexiy Chudnovskyy
<ol...@informatik.tu-chemnitz.de> 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