Hello, I've been implementing some improvements to rpc.js, and have a few more planned, so wanted to give everyone a heads-up.
Issue (https://issues.apache.org/jira/browse/SHINDIG-1050) describes a new transport mechanism I (with significant help from Joey Schorr) have implemented called RMR. Nitty-gritty details are in the code and the issue, but the upshot is that this transport is like IFPC but without an "active" relay file. It covers all known (to me) significant browsers currently using IFPC, notably Safari < 4 and Chrome < 2. With this submitted, IFPC remains somewhat useful though, since it is used as a fall-back for sending messages in certain cases when a "native" (dpm/wpm/nix/rmr/fe) transport isn't fully set up on initial page render. Messages sent during this period may otherwise be lost (and occasionally can be now, I believe). With these items in mind, I plan the following: 1. Solicit input (if any) on RMR and submit the CL ( http://codereview.appspot.com/62051). 2. Refactor rpc.js transport code into transport classes eg. WpmTransport, NixTransport, etc. Core rpc.js code will call init()/setup()/call() methods on these as appropriate, and each transport will signal to the core rpc.js library when it is ready to send messages (should any handshake be necessary). 3. Implement queueing of messages sent before transport is ready, utilizing work from #2. When the transport signals its readiness, de-queue messages and pass all subsequent calls through immediately. 4. Remove IFPC code: in rpc.js and in rpc_relay.html - assuming no remaining viable use case for it is identified in the meantime. 5. Deprecate/remove gadgets.rpc.setRelayUrl(...) method. Without IFPC the relayUrl for each gadget is simply its own URL. 6. Consider deprecation/removal of gadgets.rpc.setAuthToken(...) method. We can remove this method as well, parsing the token directly from the gadget's iframe.src, assuming we trust the gadget not to replace/remove its fragment. Comments welcome - cheers, John
