Thanks John. I agree - best to clean up the docs first. I'll try to find all the places that could use clarification and create a patch.
Ivan On Thu, Oct 29, 2009 at 17:57, John Hjelmstad <[email protected]> wrote: > Put simply, it's not implemented right now. The G <-> G js doc was put in > there a looong time ago, and the spec probably used it as inspiration. My > guess is that nobody really ever cared enough about direct G <-> G > communication to fix the js docs -- fixing the spec is a spec update of > course, discussion for [email protected]. > As noted in my initial mail, I believe the transport _could_ be implemented, > with caveats, with the addition of some bookkeeping. AFAICT, the container > would still have to be involved in that every gadget would have to get a > directory of target gadgetIds and their domains/metadata. The reason I said > wpm (or IFPC) is necessary is that the other transport techniques require > initialization to send a message. wpm/IFPC technically do not -- just pass a > message to a purported receiver's domain (through relay file or directly in > wpm). > All this being said, I'm happy to accept a Shindig patch cleaning up the > docs. > --j > On Thu, Oct 29, 2009 at 5:32 AM, Ivan Žužak <[email protected]> wrote: >> >> John, thanks for clearing up the initialization stuff, makes perfect >> sense. >> >> What confuses me still is not the underlying implementation of G-2-G >> communication (direct or routed via container), but whether G-2-G >> communication is currently even implemented in Shindig in any way. In >> other words, do: >> >> "Remote procedure call library for .... gadget-to-gadget (thru >> container) communication." (from http://bit.ly/1mcjRT) and "Provides >> operations for making remote procedure calls for .... gadget-to-gadget >> communication." (from http://bit.ly/2gfe4C) >> >> mean: >> >> 1) "you _may_ call gadgets.rpc within a gadget and pass a targetId of >> another gadget, and the rpc framework _will_ automatically route the >> message (through the container) to the destination gadget" >> >> or: >> >> 2) "calling gadgets.rpc within a gadget and passing a targetId of >> another gadget _will not_ work, but you are free to implement it >> yourself on top the existing framework"? >> >> The descriptions of the library in rpc.js and OpenSocial Gadgets spec >> strongly imply that 1) is true, but looking at the code for rpc.js and >> wpm.transport.js leads me to 2). Namely, the gadgets.rpc.call method >> accepts a "targetId" parameter, and passes it to the specific >> transport call method (as it is). Therefore, the first line of the >> call method in wpm.transport.js: >> >> var targetWin = targetId === '..' ? window.parent : >> window.frames[targetId]; >> >> will _always_ fail if the method was called from within a gadget and >> targetId is the id of another gadget (since the destination is not the >> child of the source window, rather the sibling of the source). In >> order to have container-mediated communication, it seems that the >> gadgets.rpc.call method should check if the source and destination are >> both gadgets (not the container), and if so - set the targetId to the >> container id ("..") and then let the container tunnel the message. >> >> Basically, if G-2-G communication is implemented in any way - I don't >> understand how it can possibly work for wpm transport (I think >> initialization has little to do with this). If it is not implemented, >> the documentation is very misleading. >> >> Thanks again, >> Ivan >> >> On Wed, Oct 28, 2009 at 18:19, John Hjelmstad <[email protected]> wrote: >> > A few notes. >> > >> > First, pubsub *is* gadgets.rpc underneath. It uses container mediation >> > for >> > passing messages, and its implementation specifies additional semantics >> > for >> > when messages are brokered. >> > >> > Gadgets.rpc is just a dumb socket that makes C -> G communication and G >> > -> C >> > communication possible. Consider a loose analogue with "classic" pubsub >> > - >> > without the raw network connection, the additional semantics of pubsub >> > wouldn't be possible. >> > >> > To the topics here: initializing gadgets.rpc has historically been a >> > pain. >> > As Chris notes, you need to do gadgets.rpc.setRelayUrl() and >> > gadgets.rpc.setAuthToken() in your container. You also need to make sure >> > that the gadget is rendered with an rpctoken (as noted already; random >> > number/string on the fragment) and a parent= parameter pointing back to >> > at >> > least the protocol://host:port of the container page. >> > >> > On this note, I've recently submitted a simpler initialization routine: >> > gadgets.rpc.setupReceiver(gadgetId). This makes using the library: >> > 1. Include rpc.js in container page, as currently. Let container be >> > http://c.com/container >> > 2. Render gadget IFRAME with id <gadgetId> with parameters (can be >> > fragment >> > params) #parent=http://c.com/container&rpctoken=<random> >> > 3. Call gadgets.rpc.setupReceiver(<gadgetId>); >> > >> > The need to perform an active call to set up the rpc mechanism is rooted >> > in: >> > A) the fact that the underlying message-passing implementation differs >> > per >> > browser. Most of these impls (pretty much all except window.postMessage) >> > require an initialization routine with the container performing some >> > operation on the target IFRAME to allow it to send and receive messages. >> > @see each of the *.transport.js files for descriptions of these >> > techniques. >> > B) irrespective [A], having an initialization handshake makes it >> > possible to >> > mark C <-> G "connections" as active/inactive to avoid things like >> > continuously attempting to re-establish communication, which may be a >> > lost >> > cause (one side or the other doesn't support rpc or is misconfigured) >> > and >> > would just eat browser resources. >> > >> > The vagaries of the implementation, which are a direct consequence of >> > the >> > browser security model and per-browser quirks, mean that direct G <-> G >> > communication isn't possible, unless you build a custom implementation >> > that >> > either A) is slower (eg. uses IFPC with an active relay) or B) is less >> > secure/insecure (ie. all participating gadgets are rendered on the same >> > domain as one another, breaking isolation) or C) only works on HTML5 >> > browsers (window.postMessage). Again, the reason is that the "fast" >> > techniques on non-HTML5 browsers all require active initialization. For >> > instance, NIX (IE6/7) sets the .opener property on the target IFRAME for >> > instance, which requires DOM access to the IFRAME object - not possible >> > unless you break gadget sandboxing. >> > >> > As well, gadgets.rpc's implementation could be augmented to support >> > direct G >> > <-> G communication for the above listed cases (same-domain or >> > window.postMessage, namely) transparently, as a performance enhancement. >> > That hasn't been done yet and is tricky due to API issues (specifically, >> > container-mediated G <-> G hasn't been standardized, and it's bad form >> > IMO >> > to add a sometimes-works-not-always feature) and security concerns (it's >> > often quite nice to give the container power over whether to deliver G >> > <-> G >> > messages). >> > >> > In sum, this sounds like an initialization question. Once the library is >> > set >> > up properly, you can build whatever additional communication you like >> > atop >> > it eg. unicast. >> > >> > --j >> > >> > On Wed, Oct 28, 2009 at 2:18 AM, Ivan Žužak <[email protected]> wrote: >> > >> >> 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 <[email protected]> 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 <[email protected]> >> >> > 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 <[email protected]> >> >> >> 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 <[email protected]> >> >> wrote: >> >> >>> > On Fri, Oct 16, 2009 at 4:41 PM, Ivan Žužak <[email protected]> >> >> 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:) >> >> >>> > >> >> >>> >> >> >> >> >> > >> >> >> > > >
