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