Hi John, Do you mind taking a look at this when you find the time? The first post is here: http://mail-archives.apache.org/mod_mbox/incubator-shindig-dev/200910.mbox/browser Thanks!
Ivan On Sat, Oct 17, 2009 at 17:13, Ivan Žužak <izu...@gmail.com> wrote: > 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:) >>> > >>> >> >
