Hey Kevin, Thanks for clarifying those points for me. It is unfortunate that Caja can not host Google APIs natively, is there any effort inside Google to make this possible? I imagine they would make great (internal) test cases.
I would do the debugging, and tweaking to get, at least, Google Maps supported but without the uncompiled source that would be an impossible task; A Googler on the other hand... On Thu, Feb 6, 2014 at 8:45 PM, Kevin Reid <[email protected]> wrote: > On Thu, Feb 6, 2014 at 8:55 AM, James Keane <[email protected]>wrote: > >> I intend to host applications that will require access to the Google APIs. >> >> I have tried to include the necessary javascripts inside the guest HTML, >> which did not work. I understand the limitation that iframes can not be >> hosted within a Caja guest >> > > Actually they can, though with some severe limitations currently (no > loaded documents, no distinct origins). > > >> but do not understand why for example, a simple Google Maps example will >> not work. >> > > In most cases, this is a matter of the JS in question using features not > (yet) supported by Caja -- possibly even tiny little > different-path-to-the-same-functionality ones like, for a historical > example, using .classList instead of .className (we now support classList). > These can be fixed; it's just a lot of debugging and a lot of tweaking. > > >> I have discovered the apitaming/google.maps.policyFactory.js and have >> been able to get it to work after heavy modifications to allow it to >> compile at ADVANCED_OPTIMIZATIONS. >> > > This is arguably an oversight on our part; we have made caja.js > Closure-compatible and the API taming should be too by the same argument. > However, for now I will just remind you that Closure is not actually > JavaScript, it's just a very closely related language :) > > >> The problem with this strategy though is it does not allow Apps to have >> their own API Keys forcing us to be a middleman. >> > > I recognize the problem you are describing and I currently have no > suggestions for improving the situation. > > >> Also, why does tamingGoogleLoader exist? Is it just so that guests will >> not have to provide their own API keys? >> > > It exists both for the lack-of-features reason and because some APIs (e.g. > Picker) fundamentally can't work inside the sandbox because they are using > information from a different origin, and can't practically be supported by > Caja. > > >> Also, is there a Caja externs file that I could find anywhere? I have >> been building one to implement apitaming, and it is very incomplete. >> > > No. As I said above, if we were to add Closure support for the apitaming > files, we would do it by modifying them to be Closure-compatible as caja.js > is. > -- James Keane Wishabi.com | 647-460-3634 -- IMPORTANT NOTICE: This message, including any attachments (hereinafter collectively referred to as "Communication"), is intended only for the addressee(s) named above. This Communication may include information that is privileged, confidential and exempt from disclosure under applicable law. If the recipient of this Communication is not the intended recipient, or the employee or agent responsible for delivering this Communication to the intended recipient, you are notified that any dissemination, distribution or copying of this Communication is strictly prohibited. If you have received this Communication in error, please notify the sender immediately by phone or email and permanently delete this Communication from your computer without making a copy. Thank you. -- --- You received this message because you are subscribed to the Google Groups "Google Caja Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
