The html parser already parses script tags and so knows the urls of code being included. At this point, the rewriter could substitute a known-to-cajole version if it cared to and/or inline the script. Is your concern that a library like jQuery may have been modified and/or be included from an unrecognized url and so not be recognized as jQuery? I don't really have a problem with the change you're suggesting - I'd just like to clarify the the purpose of the <Require> tag.
There are two ways in which <Require> tags are being used currently - as a powerbox to expose new functionality from the container to a gadget that could not be expressed by the apis that the gadget already has access to; and as a convenient alternative to <script> tags that point to a well-known library of functions. An example of the former is dynamic-height - a gadget cannot resize itself without help from the container; and an example of the latter is minimessage - it provides a convenient api to do things which the gadget has sufficient authority to do already. The nice thing about allowing the use of the Require tag for both of these is: * the flexibility of varying its semantics from script tags (in particular the mapping from the identifier "org.jquery.core-1.4.2" to actual code which may a modified jquery core). * the declarative syntax also makes it slightly easier for a container to know what libraries gadgets are using * once gadgets start using the Require to request libraries, the container can choose whether to provide a library via taming or cajoling. The downside is subtle and probably not a real downside. By conflating the semantics of Require to provide both a powerbox and convenience apis, containers that choose not to grant a convenience api aren't actually depriving a gadget of any power at all since the gadget can include the same API via script inclusion. On Thu, May 13, 2010 at 5:20 PM, Paul Lindner <[email protected]> wrote: > we could offer caja versions of said libraries, plus the js can be concat'd > with the rest of the payload. Lots of interesting things can fallout from > this technique. > > 2010/5/13 ๏̯͡๏ Jasvir Nagra <[email protected]> > > > On Thu, May 13, 2010 at 5:07 PM, Paul Lindner <[email protected]> wrote: > > > > > There are some features that are new, experimental and generally not > > > production ready nor standardized yet. However I'd like to see them > > > checked > > > in and maintained over time after such time they can graduate to > > > shindig-gadgets and/or shindig-social-api. > > > > > > I propose putting these new features in a new package named > > shindig-extras. > > > Code will be checked into java/extras and it will support javascript > > > features and java extensions via Guice multibindings and overrides. > > > > > > The features I want to move here are: > > > > > > * javascript features for popular javascript libraries. For example > > here's > > > org.jquery.core-1.4.2/feature.xml > > > > > > > Why would something like jQuery be a feature requested by a gadget rather > > than a script the gadget author includes with a script tag? > > > > > > > > > > <feature> > > > <name>org.jquery.core-1.4.2</name> > > > <gadget> > > > <script src=" > > > http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"/> > > > </gadget> > > > <container> > > > <script inline="true" src=" > > > http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"/> > > > </container> > > > </feature> > > > > > > > > > * New Api handlers for "Tokens" and "Apps" -- these will provide a way > to > > > create containers that run on third party web sites. > > > > > > * Anything else anyone else wants to contribute. > > > > > >
