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? How would that option be specified? Who would enhance the rewriter? > > >> >> >> >> >> >> > >> > - 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 >> >>>>> >> >>>> >> >>>> >> >>> >> >> >> > >> > >
