Actually, this is for use of JS outside the context of a direct gadget load. The canonical example are containers using gadgets.rpc, though this technique will likely be used by other containers and container-like pages on an ongoing basis.
It's somewhat akin to the Google AJAX APIs, eg: http://www.google.com/uds/?file=ads&v=1&packages=searchiframe; a "JS loader" for Shindig-supplied JS if you will. With it, statically or dynamically a page can do: <script src=" http://www.shindigserver.com/gadgets/js/lib1:lib2:lib3.js&jsload=1[&refresh=...] "></script> ...and will get a tiny piece of JS that in turn loads a much larger cached JS. The extension of this will allow dynamically-generated pages to incrementally add JS support. Use case where gadget container loads gadget X, which requires container-side JS A, B, and C. It does: <script src=" http://www.shindigserver.com/gadgets/js/A:B:C.js&?jsload=1";> Later, gadget Y is installed, which (per metadata service) requires features B and E, where E depends on A. A wrapper script (also in a later follow-up) adds: <script src=" http://www.shindigserver.com/gadgets/js/B:E.js?jsload=1&alreadyhas=A:B:C";> With this, JsServlet just omits A:B:C's JS from the output and spits out the rest. So goes the idea anyway. This is the first step, and IMO reasonably useful on its own. --j On Mon, Jun 21, 2010 at 4:23 PM, <[email protected]> wrote: > interesting.. I wonder if it would be better to inject the script node > into the head instead of using document.write? This would then result > in async/deferred js loading which may help page load performance. > > > http://codereview.appspot.com/1687043/show >
