On Mon, Jul 28, 2008 at 5:56 PM, Mike Samuel <[EMAIL PROTECTED]> wrote:
> > > 2008/7/28 Kevin Brown <[EMAIL PROTECTED]> > >> >> >> On Mon, Jul 28, 2008 at 1:04 PM, Mike Samuel <[EMAIL PROTECTED]> >> wrote: >> >>> 2008/7/28 Cassie <[EMAIL PROTECTED]> >>> >>> > Well I think it depends on who gets to make the cajoled vs non-cajoled >>> > decision. Long term my thinking was that gadget authors won't get to >>> choose. >>> > Probably 99% of them will be cajoled and some certain white listed or >>> > special gadgets will stay non-cajoled if the container wants them to. >>> > Because the container decides then the url is the best place for the >>> switch. >>> > >>> > >>> > On the other hand, if the gadget developer gets to choose whether or >>> not >>> > they are cajoled then the logic should be turned on by a require tag. >>> Short >>> > term maybe this makes more sense... so that the developers can test it >>> out >>> > in live containers? Or - you could say that they can already test >>> cajoling >>> > out in shindig... so maybe they don't need control. >>> > >>> > Anyway, so I was basically thinking that - container choice = url and >>> > gadget choice = require. >>> > So, who gets the power? :) >>> > >>> >>> Ok, so a gadget should be cajoled if the container mandates it, or the >>> gadget requests it? >>> >>> Right now, the meaning seems to be >>> url=1 -> this iframe needs to have the caja runtime JS loaded >>> <require feature-caja> -> the gadget source requires cajoling >> >> >> My take on the issue is that both solutions suck. >> >> The caja feature is useful if the goal is to have gadgets identify >> themselves as safe for cajoling, but if that's true then then caja url >> parameter is unnecessary. Containers can then make the decision as to >> whether they cajole the gadget, keep it in a sandboxed iframe, or reject it >> entirely. >> >> However, the "caja" feature is non-standard. It was only created as a >> workaround to avoid writing more code for it in Shindig. >> >> A far more appropriate solution is probably to enhance the content >> rewriter that Louis has written to support cajoling as one of the rewriting >> options. >> > > Where does that code live? > .../gadgets/rewrite/... > How would that option be specified? > I think gadgets should be flagged as cajolable externally. Anything else would require spec changes or being non-standard. > Who would enhance the rewriter? > Whoever has the time and inclination. > > > > >> >> >>> >>> >>> >>> >>> >>> > >>> > - Cassie >>> > >>> > >>> > >>> > On Mon, Jul 28, 2008 at 12:29 PM, Mike Samuel <[EMAIL PROTECTED] >>> >wrote: >>> > >>> >> So in an environment that wants to serve both cajoled and uncajoled >>> >> gadgets from the same gadget-server, the caja=1 switch is going to be >>> what >>> >> distinguishes the two long term? >>> >> >>> >> 2008/7/28 Cassie <[EMAIL PROTECTED]> >>> >> >>> >> btw - if we are confident, or if you just want to try out only needing >>> the >>> >>> caja=1 in the url, then the opensocial-current/feature.xml line 23 >>> just >>> >>> needs to be commented in. Then gadgets don't need the require. >>> >>> >>> >>> >>> >>> On Mon, Jul 28, 2008 at 11:52 AM, Cassie <[EMAIL PROTECTED]> wrote: >>> >>> >>> >>>> If we were completely confident in caja then the require feature >>> >>>> wouldn't be needed. caja would be included and turned on all of the >>> time. >>> >>>> When caja=0 the gadget would not be cajoled and so caja shouldn't >>> have any >>> >>>> affect. If caja=1 then the gadget would be cajoled and caja would do >>> all its >>> >>>> magic goodness. >>> >>>> >>> >>>> So... are we confident that caja is ready to handle both cajoled and >>> >>>> non-cajoled gadgets without causing any issues? >>> >>>> >>> >>>> - Cassie >>> >>>> >>> >>>> >>> >>>> >>> >>>> On Mon, Jul 28, 2008 at 11:04 AM, Mike Samuel <[EMAIL PROTECTED] >>> >wrote: >>> >>>> >>> >>>>> Shindiggers, >>> >>>>> >>> >>>>> There are two gates a gadget has to pass through to get cajoled >>> right >>> >>>>> now. >>> >>>>> (1) The enableCaja bit specified via ?caja=1 in the URL which adds >>> the >>> >>>>> CajaContentRewriter to the rewriter chain. >>> >>>>> (2) The <Require feature="caja"> specified in the gadget spec which >>> >>>>> causes caja.js and friends to be loaded. >>> >>>>> >>> >>>>> There doesn't seem to be any case where (1) should be different >>> from >>> >>>>> (2). Can we get rid of the need for both? >>> >>>>> >>> >>>>> I don't see an easy way for the content rewriter to be >>> conditionally >>> >>>>> added based on the presence of a <Require> >>> >>>>> element, since that decision seems to be made before the gadget >>> spec >>> >>>>> is parsed, but I don't know the code that well. Any ideas? >>> >>>>> >>> >>>>> cheers, >>> >>>>> mike >>> >>>>> >>> >>>> >>> >>>> >>> >>> >>> >> >>> > >>> >> >> >
