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:) >> >>> > >> >>> >> >> >> > >> >
