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

[Michael Nordman]

Does webcore have a 'protocol handler' abstraction that can be leveraged to
add support for a new protocol scheme?  I don't think it does, but an
abstraction like that may help with this.

On Wed, Jun 2, 2010 at 6:19 PM, Jian Li <jianli at chromium.org> wrote:

> 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
>>
>>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100603/5149dda3/attachment.html>