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 <a...@chromium.org> wrote: > On Thu, Apr 9, 2009 at 9:50 PM, David Levin <le...@google.com> wrote: >> >> On Thu, Apr 9, 2009 at 9:03 PM, Alexey Proskuryakov <a...@webkit.org> 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
