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. > > > > > > > > > > - 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 > >>>>> > >>>> > >>>> > >>> > >> > > >
