Basically, what Adobe does is break the specs. We actually had a conference call with the AIR team a while ago, where they explained what and why they where doing this.
We feel that we can't follow their reasoning by providing "security" or "functionality" by breaking the specs, so we didn't make any changes. Note that by the very nature of JavaScript, you can easily write a plugin .js file that monkeypatches Prototype to avoid the eval() calls (and maybe we can reuse that code in a future release). If AIR becomes really, really popular we might reconsider and handle this as we handle other browser quirks and bugs... :). Best, Thomas On 03.03.2008, at 09:48, John-David Dalton wrote: > > With all the buzz last week and this about frameworks being Adobe AIR > compatible. > I am wondering if the Prototype Team has tested Prototype with AIR's > new security model. > > I know prototype uses eval(), 3 times: > > String.toJSON(); // should be ok in AIR > Ajax.Request.evalResponse(); //could choke if not JSON > Selector.compileMatcher(); //should will choke on AIR > > Also I noticed some frameworks like jQuery had to adjust their browser > sniffing code for safari to include something like: !/adobeair/ > i.test(userAgent) > > More info about the AIR security model: > http://labs.adobe.com/wiki/index.php/AIR:HTML_Security_FAQ > > You might use Ext's air-adapter js and as a guide because it modifies > DOMQuery's compile method to avoid the use of eval(). > > -JD > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~----------~----~----~----~------~----~------~--~---
