Put simply, it's not implemented right now. The G <-> G js doc was put in there a looong time ago, and the spec probably used it as inspiration. My guess is that nobody really ever cared enough about direct G <-> G communication to fix the js docs -- fixing the spec is a spec update of course, discussion for opensocial-and-gadget-s...@googlegroups.com.
As noted in my initial mail, I believe the transport _could_ be implemented, with caveats, with the addition of some bookkeeping. AFAICT, the container would still have to be involved in that every gadget would have to get a directory of target gadgetIds and their domains/metadata. The reason I said wpm (or IFPC) is necessary is that the other transport techniques require initialization to send a message. wpm/IFPC technically do not -- just pass a message to a purported receiver's domain (through relay file or directly in wpm). All this being said, I'm happy to accept a Shindig patch cleaning up the docs. --j On Thu, Oct 29, 2009 at 5:32 AM, Ivan Žužak <izu...@gmail.com> wrote: > John, thanks for clearing up the initialization stuff, makes perfect sense. > > What confuses me still is not the underlying implementation of G-2-G > communication (direct or routed via container), but whether G-2-G > communication is currently even implemented in Shindig in any way. In > other words, do: > > "Remote procedure call library for .... gadget-to-gadget (thru > container) communication." (from http://bit.ly/1mcjRT) and "Provides > operations for making remote procedure calls for .... gadget-to-gadget > communication." (from http://bit.ly/2gfe4C) > > mean: > > 1) "you _may_ call gadgets.rpc within a gadget and pass a targetId of > another gadget, and the rpc framework _will_ automatically route the > message (through the container) to the destination gadget" > > or: > > 2) "calling gadgets.rpc within a gadget and passing a targetId of > another gadget _will not_ work, but you are free to implement it > yourself on top the existing framework"? > > The descriptions of the library in rpc.js and OpenSocial Gadgets spec > strongly imply that 1) is true, but looking at the code for rpc.js and > wpm.transport.js leads me to 2). Namely, the gadgets.rpc.call method > accepts a "targetId" parameter, and passes it to the specific > transport call method (as it is). Therefore, the first line of the > call method in wpm.transport.js: > > var targetWin = targetId === '..' ? window.parent : > window.frames[targetId]; > > will _always_ fail if the method was called from within a gadget and > targetId is the id of another gadget (since the destination is not the > child of the source window, rather the sibling of the source). In > order to have container-mediated communication, it seems that the > gadgets.rpc.call method should check if the source and destination are > both gadgets (not the container), and if so - set the targetId to the > container id ("..") and then let the container tunnel the message. > > Basically, if G-2-G communication is implemented in any way - I don't > understand how it can possibly work for wpm transport (I think > initialization has little to do with this). If it is not implemented, > the documentation is very misleading. > > Thanks again, > Ivan > > On Wed, Oct 28, 2009 at 18:19, John Hjelmstad <fa...@google.com> wrote: > > 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:) > >> >>> > > >> >>> > >> >> > >> > > >> > > >
