The gadget topics are coded in the gadget xml, developers call the gadgets.Hub.publish or subscribe function directly. It seems that such gadget to gadget communication is defined by gadget developer. The use case I am trying to have is that the end user or the container of the gadgets, can somehow have the ability to connect the gadget instances through topics.
Quote from http://opensocial-resources.googlecode.com/svn/spec/2.0.1/Core-Gadget.xml, C.12.6 Wiring Metadata: The OpenSocial specification defines additional metadata that can be used to describe the events that a gadget publishes or to which it is able to subscribe. This allows the container to automatically "wire" gadgets together, and/or provide a UI that allows the user to wire publisher gadgets to subscriber gadgets. For example, manual wiring is often necessary because there sometimes are multiple widgets publishing to or subscribing to the same topic, such as "date", where one widget might provide a start date and the other widget an end date, and also because sometimes topic names and/or payload types are too generic for automatic mapping. I searched in the common container source code, but I didn't find any related implementation to support end user to wire gadget instances. If pub-sub feature is not the one that I should leverage to implement such use case, do you have any other recommendation? Thanks Best Regards Marshall Shi(Shi Wei) Craig McClanahan <craigmcc@gmail.c om> To dev@shindig.apache.org 2011-12-29 16:46 cc Subject Please respond to Re: dynamic wire for gadgets dev@shindig.apach e.org On Thu, Dec 29, 2011 at 12:23 AM, Wei CSDL Shi <shiwc...@cn.ibm.com> wrote: > Yes, I am looking for how to setup wire between specific gadget instances. > I've checked the gadget topics, it seems that once gadget A published a > topic, all the gadget B instances which subscribed to that topic, will be > invoked. Is there a way that I can only invoke one specific gadget B > instance when I publish a topic? > That desire seems totally opposite of the whole reason that pub-sub architectures exist in the first place. The basic idea is that gadget A says "here is something that happened" with absolutely no knowledge about who might or might not be listening. The fundamental principle is to separate the event producers and the event listeners, after all. If you care about a particular B being the only one receiving that notification, why not set up a private topic that only that particular B instance listens to? Or use some completely separate 1:1 mechanism, since pub-sub is obviously not what you really want? Craig McClanahan
