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