As this change is only introducing a js dependency on caja couldn't we have caja host their js file in a well known location - and then have the feature pull from the web? This is currently how the analytics feature works.
- Cassie On Fri, Aug 15, 2008 at 12:14 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > On Fri, Aug 15, 2008 at 11:47 AM, Brian Eaton <[EMAIL PROTECTED]> wrote: > > > Ugh. > > > > We need a way for PHP to depend on Caja, or we need to get > > gadgets.util.sanitizeHtml pulled out of the opensocial spec, or we > > need to accept that PHP Shindig will never implement that function. > > > None of these are required. Implementing sanitizeHtml does *NOT* require > using caja's sanitizer, it was just proposed as a convenient way to do it. > > Shindig *MUST* implement the function. It's a reference implementation. Not > implementing it is unacceptable. > > > > > > > > For now we can probably make the implementation of > > gadgets.util.sanitizeHtml dependent on the presence of the Caja HTML > > sanitization code. > > > > On Fri, Aug 15, 2008 at 11:41 AM, Chris Chabot <[EMAIL PROTECTED]> > wrote: > > > I build in a 'ignore anything that starts with res://' into the feature > > > parsing a while ago already (back then it was the caja changes that > made > > php > > > shindig upset), so the changes doesn't cause the world to burn > directly. > > > > > > However the file won't be included by php shindig either, so please > that > > > keep in mind before building something that depends on it, otherwise > you > > > could break quite a few social sites :) > > > > > > On Aug 15, 2008, at 8:22 PM, Josh Landin wrote: > > > > > >> I agree. > > >> > > >> On 8/15/08, Kevin Brown <[EMAIL PROTECTED]> wrote: > > >>> > > >>> Requiring PHP users to build, download, and manage a jar (not to > > mention > > >>> adding the code to deal with it to the PHP build) to get one > javascript > > >>> file > > >>> is completely unreasonable. > > > > > > > > >
