Yes, making changes as discussed in bugzilla, plus removing
registerURLSchemeAsLocal would be a fine direction.
- WBR, Alexey Proskuryakov
On 12.04.2009, at 22:58, Aaron Boodman wrote:
It sounds to me like our current patch is the best fit because it fits
our needs, will work with Chromium's out-of-process workers, plus it
allows us to remove FrameLoader::registerURLSchemeAsLocal() as Alexey
requested. It has the downside that the client will get called on
multiple threads, but this will automatically be fixed when the
DocumentThreadableLoader refactor work is done.
Can I get a yay or nay (from Alexey or other interested people) on
moving forward with that patch? We're happy to do the work to remove
registerURLSchemeAsLocal() while we're in there.
Alternatively, can I get an idea for a different approach that would
be accepted?
Thanks,
- a
On Fri, Apr 10, 2009 at 10:23 AM, Aaron Boodman <[email protected]>
wrote:
On Thu, Apr 9, 2009 at 9:50 PM, David Levin <[email protected]> wrote:
On Thu, Apr 9, 2009 at 9:03 PM, Alexey Proskuryakov
<[email protected]> wrote:
On 09.04.2009, at 22:38, Aaron Boodman wrote:
The local scheme feature is actually more powerful than just XHR
If you only need extensions to do XHR, why not just make them use
cross-origin XHR? That way, the extension won't even need to
declare the
origins it's going to access - all checks will be server-side, as
with
normal cross-origin XHR.
I think the idea is that a user could install an extension and the
user
could trust the extension to do the cross-origin xhr (without the
server for
the x-origin doing anything special).
For example, I used to have the book burro FF extension
(http://www.bookburro.org/) which displayed prices for books from
several
book stores when you visit another online book store.
Exactly. Sorry for not making this clear in the original mail.
- a
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
