A few notes. First, pubsub *is* gadgets.rpc underneath. It uses container mediation for passing messages, and its implementation specifies additional semantics for when messages are brokered.
Gadgets.rpc is just a dumb socket that makes C -> G communication and G -> C communication possible. Consider a loose analogue with "classic" pubsub - without the raw network connection, the additional semantics of pubsub wouldn't be possible. To the topics here: initializing gadgets.rpc has historically been a pain. As Chris notes, you need to do gadgets.rpc.setRelayUrl() and gadgets.rpc.setAuthToken() in your container. You also need to make sure that the gadget is rendered with an rpctoken (as noted already; random number/string on the fragment) and a parent= parameter pointing back to at least the protocol://host:port of the container page. On this note, I've recently submitted a simpler initialization routine: gadgets.rpc.setupReceiver(gadgetId). This makes using the library: 1. Include rpc.js in container page, as currently. Let container be http://c.com/container 2. Render gadget IFRAME with id <gadgetId> with parameters (can be fragment params) #parent=http://c.com/container&rpctoken=<random> 3. Call gadgets.rpc.setupReceiver(<gadgetId>); The need to perform an active call to set up the rpc mechanism is rooted in: A) the fact that the underlying message-passing implementation differs per browser. Most of these impls (pretty much all except window.postMessage) require an initialization routine with the container performing some operation on the target IFRAME to allow it to send and receive messages. @see each of the *.transport.js files for descriptions of these techniques. B) irrespective [A], having an initialization handshake makes it possible to mark C <-> G "connections" as active/inactive to avoid things like continuously attempting to re-establish communication, which may be a lost cause (one side or the other doesn't support rpc or is misconfigured) and would just eat browser resources. The vagaries of the implementation, which are a direct consequence of the browser security model and per-browser quirks, mean that direct G <-> G communication isn't possible, unless you build a custom implementation that either A) is slower (eg. uses IFPC with an active relay) or B) is less secure/insecure (ie. all participating gadgets are rendered on the same domain as one another, breaking isolation) or C) only works on HTML5 browsers (window.postMessage). Again, the reason is that the "fast" techniques on non-HTML5 browsers all require active initialization. For instance, NIX (IE6/7) sets the .opener property on the target IFRAME for instance, which requires DOM access to the IFRAME object - not possible unless you break gadget sandboxing. As well, gadgets.rpc's implementation could be augmented to support direct G <-> G communication for the above listed cases (same-domain or window.postMessage, namely) transparently, as a performance enhancement. That hasn't been done yet and is tricky due to API issues (specifically, container-mediated G <-> G hasn't been standardized, and it's bad form IMO to add a sometimes-works-not-always feature) and security concerns (it's often quite nice to give the container power over whether to deliver G <-> G messages). In sum, this sounds like an initialization question. Once the library is set up properly, you can build whatever additional communication you like atop it eg. unicast. --j On Wed, Oct 28, 2009 at 2:18 AM, Ivan Žužak <izu...@gmail.com> wrote: > Hi John, > > Do you mind taking a look at this when you find the time? The first > post is here: > http://mail-archives.apache.org/mod_mbox/incubator-shindig-dev/200910.mbox/browser > Thanks! > > Ivan > > On Sat, Oct 17, 2009 at 17:13, Ivan Žužak <izu...@gmail.com> wrote: > > Hey Chris, > > > > The gadgets.rpc feature is a part of the official spec - > > > http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Gadgets-API-Specification.html#gadgets.rpc > . > > However, the publish-subscribe mechanism feature which OAA is also > > working on isn't in the official OpenSocial spec. Thanks for the > > pointer to the OpenSocial thread - I'm actually very interested in > > where widgets and inter-widget communication are going and will keep > > an eye on what Mark is doing. > > > > The project I'm working on (http://geppeto.fer.hr/) requires unicast > > inter-widget communication for which, although it could be mimicked > > with pub-sub, rpc would be a better fit. We've gotten around the > > issue, but would now just like to find our if we were doing something > > wrong or G2G rpc communication isn't supposed be working anyway. > > > > With hope that I won't be considered annoying, I've added John > > Hjelmstad to the thread. As far as I can see by the SVN commits, John > > implemented the gadgets.rpc feature and can hopefully shed some light > > on this. John - you probably don't remember me, but we've met a few > > times while I was interning at Google back in 2007. Adam Sah was my > > mentor and together with another intern, Doug Coker and Adam I worked > > on the initial implementation of the pub-sub feature for Google > > Gadgets. > > > > Thanks, > > Ivan > > > > On Sat, Oct 17, 2009 at 12:40, Chris Chabot <chab...@google.com> wrote: > >> From what I understand gadget-to-gadget communication is the goal of > that > >> feature, it is container mediated, partially I guess since on many > >> containers each gadget has it's own unique domain as to block direct > >> gadget-to-gadget interaction (which is a security risk), but that should > >> 'work' without modifications. > >> > >> rpc isn't an official spec feature at the moment and hasn't seen a lot > of > >> love, however IBM and some others have taken an interest in > >> cross-gadget-rpc'ing in OpenSocial and are working on a new proposal > that's > >> based on OpenAjax's RPC methodology, there's some details here: > >> > http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/951b8e86c3782b86/e7ce4e22e1ed9929?show_docid=e7ce4e22e1ed9929&pli=1 > >> > >> If you have a strong need for a better RPC mechanism, you could contact > Mark > >> and see how you could be involved, or if you're ok with waiting a bit, > >> taking a wait and see approach to see what they'll produce :) > >> > >> On Sat, Oct 17, 2009 at 9:40 AM, Ivan Žužak <izu...@gmail.com> wrote: > >> > >>> Chris, you're right - I need those anyway so thanks for the partuza > >>> example. :) > >>> > >>> I've actually gotten around the gadget-to-gadget issue by modifying > >>> the rpc code a bit. I just wanted to find out why this isn't supported > >>> out-of-the-box - does it introduce any security issues or is this not > >>> though of as a useful use case? > >>> > >>> Thanks for the help, Chris! > >>> Ivan > >>> > >>> On Fri, Oct 16, 2009 at 20:56, Chris Chabot <chab...@google.com> > wrote: > >>> > On Fri, Oct 16, 2009 at 4:41 PM, Ivan Žužak <izu...@gmail.com> > wrote: > >>> > > >>> >> Hey Chris, > >>> >> > >>> >> 1) The container does load the rpc library. > >>> >> 2) Each gadget on the container is loaded from a URL that does > contain > >>> >> a rpc token in the fragment part. > >>> >> 3) I do not see the setRelayUrl and setAuthToken calls. Is this > >>> >> something that should be automatically generated without my > >>> >> intervention into shindig code or something that requires changing > >>> >> shindig? As I understand, these calls should be placed on the > >>> >> container not in each gadget? > >>> >> > >>> > > >>> > This is something you should add to your container code, ie in the > part > >>> that > >>> > generates the gadget iframe's, as a practical example this is how > they're > >>> > generated in Partuza: > >>> > > >>> > http://code.google.com/p/partuza/source/browse/trunk/Application/Views/gadget/gadget.php > >>> > > >>> > > >>> > > >>> > > >>> >> In any case, does gadget-to-gadget communication go through the > >>> >> container or directly between two iframes? If I interpret the code > >>> >> correctly, the setRelayUrl and setAuthToken calls enable > communication > >>> >> between container and gadget, not between two gadgets - when > >>> >> gadgets.rpc.call is invoked within a gadget and an ID which is not > the > >>> >> container is specified, the wpm transport fails when trying to > obtain > >>> >> the destination frame since window.frames[targetId] is undefined > >>> >> (since the target is not a child of the gadget, rather it's > sibling). > >>> >> > >>> > > >>> > Correct, I thought the RPC calls were container mediated, but I > haven't > >>> > personally looked at that code for a while so I'm hoping that by > adding > >>> > those 2 calls things might magically start to work, and if not you > needed > >>> > those anyhow:) > >>> > > >>> > >> > > >
