[webkit-dev] How to handle a new protocol for Blob.url support?

[Jian Li]

This will probably work for most of the platforms, except the one that uses
multi-process architecture. How do we handle the case that a page is trying
to access a blob URL that is created in another process (assume the
accessing page is in the same security domain)? I think for the platform,
like Chromium, we can choose to delegate to the host to do the right job,
while all other platforms will share the same handling logic defined at a
higher level.

In addition, we might need to hook up additional logic if we want to support
using it in the shared worker process.


On Wed, Jun 2, 2010 at 6:08 PM, Darin Adler <darin at apple.com> wrote:

> On Jun 1, 2010, at 5:14 PM, Jian Li wrote:
>
> I am working on Blob.url support as defined in the latest version of File
> API (http://dev.w3.org/2006/webapi/FileAPI/). The Blob.url will return a
> URL that can be used to refer to the blob object in a resource request, like
> blobdata:f81d4fae-7dec-11d0-a765-00a0c91e6bf6. The blob object can represent
> a whole file, a partial file (created by Blob.slice), or a byte array
> (created by BlobBuilder defined in the FileWriter spec). What is the right
> place I can hook up with in order to interpret and process the blobdata
> request? Should it be in the WebKit library layer that will be implemented
> by individual platform or in the higher layer like what application cache
> does the work?
>
>
> Definitely a higher level. We don’t want to have to reimplement a feature
> like this for each platform.
>
>     -- Darin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100602/5239ce85/attachment-0001.html>