Hey Ryan, The sibling mechanism in rpc isn't really sibling -- it's "top-relative" and only works with window.postMessage. Basically if you send a message to "/foo" you're sending directly to the iframe with name "foo" that's child of top.
The relay URL is a legacy concept -- it was used back when IFPC was the only mechanism available, requiring a special HTML file shared on the domain of a receiver, in order to pass messages. This was painful b/c you needed to host the relay, and slow b/c each message caused a frame reload (cached, but still taking up resources). I've actually written a blue-sky version of rpc internal to Google that supports arbitrary-to-arbitrary message communication, with only 2 transports: wpm and flash, covering all browsers. I'm asking folks here whether I can contribute it to Shindig, if for no other reason than to be illustrative of some of our current thinking in code. --j On Thu, Sep 1, 2011 at 11:17 AM, Ryan J Baxter <[email protected]> wrote: > Thanks John, this at least confirms what I was thinking. > > >That doesn't discount the value of gadget-to-gadget communication though > -- > >it just provides a number of caveats built into the browser model for it. > >For instance, we use sibling-to-sibling communication for authenticated > data > >access via a shared top-level IFRAME, which has a known/stable ID, > secured > >by domain. > > I saw sibling mentioned in the code as well, and I did not really > understand it to well. So in this scenario, the shared top level iFrame > is an iFrame in the container page right? And you're saying there are > siblings of that iFrame, which send messages back and forth through that > top-level iFrame, correct? Is this what the relay URL is in the RPC code? > Or is the relay URL just used for cross domain container to gadget > communication? > > -Ryan > > Email: [email protected] > Phone: 978-899-3041 > developerWorks Profile > > > > From: John Hjelmstad <[email protected]> > To: Ryan J Baxter/Westford/IBM@Lotus, > Cc: [email protected] > Date: 09/01/2011 01:17 PM > Subject: Re: Gadget To Gadget RPC > > > > Hey Ryan, > > You've pretty much hit the fundamental difficulty with any non-direct > in-page communication: the intermediary always has some degree of control. > > Like you're saying, what you need is either an ID service of some kind, or > a > reliable convention in the context in which you're operating, to > communicate > effectively. > > In neither case can you necessarily trust the "true" identity of your > recipient, because it can be changed from underneath you, eg. in an > untrusted container context. You can use a recipient domain (postMessage > and > Flash transports support this, covering all browsers) and/or some method > of > in-browser crypto (eg. using Stanford's lib: ) to secure communication. > > That doesn't discount the value of gadget-to-gadget communication though > -- > it just provides a number of caveats built into the browser model for it. > For instance, we use sibling-to-sibling communication for authenticated > data > access via a shared top-level IFRAME, which has a known/stable ID, secured > by domain. > > I'd say pubsub is the right solution when A) you trust your container, as > it's a container-mediated technique and B) when you don't care exactly who > your recipients are -- you just know that you're operating in a context > where other, loosely connected components might be as well, exchanging > information. > > One idea I'd heard kicked around is use of a pubsub-like technique to * > acquire* gadget/component IDs on the page. Essentially a filtered, opt-in > version of the directory service, the subject would be "I have address X, > publish on Y1,Y2 and listen on Z1,Z2". Responses would come direct from > participants indicating their corresponding state. > > Hope this helps, > John > > On Thu, Sep 1, 2011 at 6:50 AM, Ryan J Baxter <[email protected]> wrote: > > > Over the past few days I have been looking at gadget to gadget RPC calls > > and I am kind of puzzled. > > > > If gadget 1 wants to make and RPC call to gadget 2 it needs to know the > > "id" of gadget 2. I believe, after looking through the code, that the > "id" > > is actually the iframe id. However this doesn't make sense to me > because > > there is no way when you're in the context of gadget 1 to find the > iframe of > > gadget 2. I guess the over arching question is how would one gadget > know > > the id of another gadget in order to make the RPC call to it. If the > ids > > are equal to the iframe id, than those ids could potentially be > different in > > every container. Without a service provided by the container to provide > the > > gadget id for a gadget, it would be very difficult to do gadget to > gadget > > RPC calls. > > > > Maybe gadget to gadget RPC calls are easier when the gadgets are > cajoled? > > Is pub sub a better way to do gadget to gadget communication? Should > RPC > > only be used for gadget to container communication? > > > > -Ryan > > > > Email: [email protected] > > Phone: 978-899-3041 > > developerWorks Profile< > > http://www.ibm.com/developerworks/mydeveloperworks/profiles/user/RyanJBaxter > > > > > > > >
