Status of Caja Project?
pcj opened this issue · 6 comments
Can the Caja developers comment on the state of the Caja project? A few concerning observations are:
- caja.appspot.com has been broken for awhile now and nobody seems to care / comment.
- Google Apps script deprecated sandbox modes other than IFRAME, which I interpret as a move away from Caja.
- Low volume of updates and attention to issues (on Github).
In any case, I think the ideas behind Caja are still great and I'd like to see it continue and grow, but I'm wondering what's happening.
Thanks in advance,
Paul
Caja is maintained by three-ish engineers in their spare time, one of
whom only works on SES. Apps script is indeed moving away from caja,
for a few reasons:
- developers are OK with using an asynchronous API for communication
between sandboxed code and Google APIs - users don't care about confinement; there's no demand for, say, a
text editor that can't leak your files to the app developer - everyone hates wrapping the dom
The new sandboxed iframe that all browsers implement is good enough
for the purposes of apps script. Caja is still the only sandbox that
provides confinement and synchronous interaction between guest code
and the host page. I think it's an excellent choice for anyone who
wants to add user scripting to a web app.
On Thu, Nov 19, 2015 at 1:07 PM, Paul Cody notifications@github.com wrote:
Can the Caja developers comment on the state of the Caja project? A few
concerning observations are:caja.appspot.com has been broken for awhile now and nobody seems to care /
comment.Google Apps script deprecated sandbox modes other than IFRAME, which I
interpret as a move away from Caja.Low volume of updates and attention to issues (on Github).
In any case, I think the ideas behind Caja are still great and I'd like to
see it continue and grow, but I'm wondering what's happening.Thanks in advance,
Paul—
Reply to this email directly or view it on GitHub.
Mike Stay - metaweta@gmail.com
http://www.cs.auckland.ac.nz/~mike
http://reperiendi.wordpress.com
Thanks for your comments and quick reply.
Can you comment on compatibility with the closure compiler? I tried putting caja.js in with a plovr-based project and it did not work, got as far as tracking down where gman.document.imports disappeared to after an ADVANCED compile.
I wrote a quick caja.ext.js extern file though, loading caja.js dynamically later in a web-app, and that did work. I can use it like that but I would be nice to have dead-code elimination.
Thanks,
Paul
I don't know enough about that to comment. Mark, Kevin?
On Fri, Nov 20, 2015 at 7:47 AM, Paul Cody notifications@github.com wrote:
Thanks for your comments and quick reply.
Can you comment on compatibility with the closure compiler? I tried
putting caja.js in with a plovr-based project and it did not work, got as
far as tracking down where gman.document.imports disappeared to.I wrote a quick caja.ext.js extern file though, loading caja.js
dynamically later in a web-app, and that did work. I can use it like that
but I would be nice to have dead-code elimination.Thanks,
Paul—
Reply to this email directly or view it on GitHub
#1986 (comment).
Mike Stay - metaweta@gmail.com
http://www.cs.auckland.ac.nz/~mike
http://reperiendi.wordpress.com
We should ask Felix... he did a lot of the initial compatibility work with closure. Unfortunately the way caja is written doesn't lend itself well to many of the closure optimizations although deaf code elimination should work.
Sorry, it's been a while since I looked at that, I don't remember much
about it any more.
On Sat, Nov 21, 2015 at 11:53 AM, Jasvir Nagra notifications@github.com
wrote:
We should ask Felix... he did a lot of the initial compatibility work with
closure. Unfortunately the way caja is written doesn't lend itself well to
many of the closure optimizations although deaf code elimination should
work.—
Reply to this email directly or view it on GitHub
#1986 (comment).
Closing this as it isn't something that needs action. Please send further questions to google-caja-discuss@googlegroups.com.