We just tagged a new version of Chromeless and wrote a short blog post describing the new features and path forward:
http://mozillalabs.com/chromeless/?p=47
Look forward to your feedback!
best,
lloyd
> There's a small bug in the docs. The last two links under the Tutorial
> section ("Your First App" and "Using require()) don't change the page
> content at all.
Yuck. Those are placeholders that were left in. Basic introductory docs
need to get written:
https://github.com/mozilla/chromeless/issues/89
thanks for the report!
lloyd
On Apr 29, 2011, at 3:30 PM, Gordon Mohr wrote:
> Hi!
>
> Hearing about Chromeless made me think of a few questions, for which I
> didn't find clear answers in the existing docs.
>
> • Can a Chromeless-built app auto-update the rendering code with
> urgent fixes as they become available on the FF4 mainline?
We've done absolutely nothing with auto-update yet. I've spent some
time thinking about it. Currently in my mind I think it might be
nice to build a library that is capable of updating either application
code, or runtime, or both. The developer experience of integrating
this facility might be something like:
1. create keypair
2. embed pubkey in app
3. call into the "app-update" library at various points in your application
4. put a json file and two update bundles in a well known location on your
server
5. embed that well known location inside your application
Ideally it would be that easy to get secure and efficient app updating.
I've got lots of ideas (LZMA being one) as we did something like this in
a previous project that I worked on.
But this is all ideaware at the moment. I'd love to hear your thoughts.
> • Will a Chromeless app automatically (or optionally) share plug-ins
> (such as Flash) with the local full browser install?
Not implemented, in scope. (actually, should be *really* easy).
> • When displaying untrusted web content, can the Chromeless-built app
> intercept and alter any requests from the untrusted frame?
> Essentially, I'd like to act like a local in-process proxy that could,
> at its own discretion, change the destination URL or perform arbitrary
> changes on requests-from/responses-to the web content frame. (And
> perhaps one alternative way to effect this would be to ensure the
> Chromeless app uses a specific, perhaps-local, HTTP proxy for all web
> access – before and separate from any systemwide/normal-browser proxy
> settings.)
Not implemented, in scope. if you look at the source of the web-content.js
library, most of the hooks we need are there. So again, not a lot of
lines of code, but tractable imo.
thanks for sharing your thoughts!
lloyd
> --
> You received this message because you are subscribed to the Google Groups "mozilla-labs" group.
> To post to this group, send email to mozill...@googlegroups.com.
> To unsubscribe from this group, send email to mozilla-labs...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mozilla-labs?hl=en.
>
>