Top is whatever top is :) That is to say, it's typically the container page but it's also possible that the container is itself IFRAMEd.
--j On Fri, Sep 2, 2011 at 5:32 AM, Ryan J Baxter <[email protected]> wrote: > Thanks for the info John. If I am understanding you correctly, "top" > would be the container page? > > -Ryan > > Email: [email protected] > Phone: 978-899-3041 > developerWorks Profile > > > > From: John Hjelmstad <[email protected]> > To: [email protected], > Date: 09/01/2011 04:11 PM > Subject: Re: Gadget To Gadget RPC > > > > 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 > > > > > > > > > > > > > > > > > > >
