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