Getting rid of IFPC brings the gzipped size down to around 2k, which was my personal preference.
Compared to the opensocial-0.8, or even 'core', though, rpc is pretty small. Those libraries weigh in at 30k and 10k, respectively. On Wed, Jun 10, 2009 at 7:06 AM, Paul Lindner <[email protected]> wrote: > Of all the optimizations out there this seems like the least interesting > and > more disruptive than necessary. The (current) whole of rpc.js is > 6285 Jun 8 13:28 ./features/target/classes/features/rpc/rpc.opt.js > > Making this 6k private instead of CDN cacheable would mean that I would > have > to find another 6k to move onto the CDN to insure that I (and others) hit > our cold-cache numbers for loading profile / home pages. > > Do you mind sharing your goals here? What kind of byte-savings are you > expecting? > > Is it not possible to have the browser send a filtering parameter along > with > the request? The getRelayChannel() function figures out your capabilities > based on what the browser can do, not the value of it's > UA. For example there are some people that change their User-Agent to > (mostly) Internet Explorer to get around server restrictions. These people > would get broken nix. > > I just wonder if there are other ways to achieve the wanted byte savings? > > > On Tue, Jun 9, 2009 at 2:18 PM, John Hjelmstad <[email protected]> wrote: > > > I'm sold, relying on Cache-Control: private is the better option. > > This behavior does affect IFRAME rendering paths as well, though doesn't > > necessarily need to. Container-side rpc can be optimized without > > gadget-side > > rpc, since gadgets.rpc(function getRelayChannel()) will return the same > > value on each side. > > > > As Brian mentions, every code path in GadgetRenderingServlet sets > > Cache-Control: private[,*] (except nocache=1, not an issue), so the > > potential effects are limited to JsServlet. > > > > So 1. Admittedly, any given deployment will likely see higher JsServlet > > traffic if choosing to opt into this feature; 2. this suggests that > > JsLibrary field isBrowserSpecific should be added, with JsServlet > signaling > > noProxy behavior in caching headers when this bit is true for any library > > it > > emits. > > > > John > > > > On Tue, Jun 9, 2009 at 1:53 PM, Brian Eaton <[email protected]> wrote: > > > > > I don't trust the vary header any farther than I can spit. > > > > > > For example, at least one version of IE interprets a Vary header with > > > any value other than user-agent to mean "OMG, I don't understand, > > > don't cache this": > > > http://marc.info/?l=apache-modgzip&m=103958533520502&w=2 > > > > > > In a comment to Mark's blog post, he mentions other implementation > > issues: > > > > > > "More complex situations -- e.g., with multiple Vary headers and > > > multiple request headers -- caused problems on a number of > > > implementations (i.e., they'd return the wrong thing)." > > > > > > IMHO, we should stick to "cache-control: private." > > > > > > We need that on most iframes anyway, so this keeps the cache-control > > > changes from rippling out quite so far. > > > > > > On Tue, Jun 9, 2009 at 1:44 PM, John Panzer<[email protected]> wrote: > > > > This seems relevant: > http://www.mnot.net/blog/2007/06/20/proxy_caching > > > > (It appears that Vary: is fairly safe in the sense that caches that > > don't > > > > deal with it nicely -- e.g., caching variants -- will just mark the > > > content > > > > as uncacheable. Though I don't think this was rigorously tested.) > > > > > > > > -- > > > > John Panzer / Blogger > > > > [email protected] / abstractioneer.org < > > http://www.abstractioneer.org/> > > > / > > > > @jpanzer > > > > > > > > > > > > > > > > On Tue, Jun 9, 2009 at 1:25 PM, <[email protected]> wrote: > > > > > > > >> Hi Paul: > > > >> > > > >> You're absolutely right. Vary: User-Agent; is preferable to me. Do > you > > > >> have any reason in mind for why Cache-Control: private in addition > to > > or > > > >> instead of Vary would be preferable? Ie. common support by various > > CDNs. > > > >> > > > >> I've been thinking how best to link service of custom rpc to setting > > > >> this header. Ultimately JsServlet or a Filter needs to do so. > Thoughts > > > >> on this? The best idea I had was to add something like > > > >> isBrowserSpecific() to JsLibrary so that the relevant output code > > > >> (gadget rendering, js servlet) could act accordingly. > > > >> > > > >> Kevin - re: StringBuffer, comment isn't particularly prescriptive so > > > >> I'll assume the complaint is use of StringBuffer rather than > > > >> StringBuilder. If so, fixed. If not, let me know. > > > >> > > > >> > > > >> http://codereview.appspot.com/63210 > > > >> > > > > > > > > > >
