On Wed, Sep 15, 2010 at 3:31 PM, Maciej Stachowiak wrote:
>
> On Sep 15, 2010, at 1:06 PM, Darin Fisher wrote:
>
> On Wed, Sep 15, 2010 at 12:56 PM, Maciej Stachowiak wrote:
>
>>
>> On Sep 15, 2010, at 9:15 AM, Darin Fisher wrote:
>>
>> On Wed, Sep 15, 2010 at 8:58 AM, Alexey Proskuryakov wrote:
On Sep 15, 2010, at 2:05 PM, Adam Barth wrote:
> On Wed, Sep 15, 2010 at 1:09 PM, Darin Fisher wrote:
>> I'm ignoring javascript: URLs because they are super weird... evaluation
>> happens synchronously and can have side effects such as causing other
>> navigations. It does not fit the normal m
On Sep 15, 2010, at 1:06 PM, Darin Fisher wrote:
> On Wed, Sep 15, 2010 at 12:56 PM, Maciej Stachowiak wrote:
>
> On Sep 15, 2010, at 9:15 AM, Darin Fisher wrote:
>
>> On Wed, Sep 15, 2010 at 8:58 AM, Alexey Proskuryakov wrote:
>>
>> 14.09.2010, в 22:15, Darin Fisher написал(а):
>>
>> > I t
On Wed, Sep 15, 2010 at 1:09 PM, Darin Fisher wrote:
> I'm ignoring javascript: URLs because they are super weird... evaluation
> happens synchronously and can have side effects such as causing other
> navigations. It does not fit the normal mold of URL loading. Mozilla tries
> to express javasc
On Wed, Sep 15, 2010 at 9:15 AM, Darin Fisher wrote:
> On Wed, Sep 15, 2010 at 8:58 AM, Alexey Proskuryakov wrote:
>
>>
>> 14.09.2010, в 22:15, Darin Fisher написал(а):
>>
>> > I think it makes sense to extend ResourceHandle.cpp to access the
>> BlobRegistry singleton in order to support blob URL
On Wed, Sep 15, 2010 at 1:06 PM, Darin Fisher wrote:
> On Wed, Sep 15, 2010 at 12:56 PM, Maciej Stachowiak wrote:
>
>>
>> On Sep 15, 2010, at 9:15 AM, Darin Fisher wrote:
>>
>> On Wed, Sep 15, 2010 at 8:58 AM, Alexey Proskuryakov wrote:
>>
>>>
>>> 14.09.2010, в 22:15, Darin Fisher написал(а):
>>
On Wed, Sep 15, 2010 at 12:56 PM, Maciej Stachowiak wrote:
>
> On Sep 15, 2010, at 9:15 AM, Darin Fisher wrote:
>
> On Wed, Sep 15, 2010 at 8:58 AM, Alexey Proskuryakov wrote:
>
>>
>> 14.09.2010, в 22:15, Darin Fisher написал(а):
>>
>> > I think it makes sense to extend ResourceHandle.cpp to acce
On Sep 15, 2010, at 9:15 AM, Darin Fisher wrote:
> On Wed, Sep 15, 2010 at 8:58 AM, Alexey Proskuryakov wrote:
>
> 14.09.2010, в 22:15, Darin Fisher написал(а):
>
> > I think it makes sense to extend ResourceHandle.cpp to access the
> > BlobRegistry singleton in order to support blob URLs.
>
On Wed, Sep 15, 2010 at 8:58 AM, Alexey Proskuryakov wrote:
>
> 14.09.2010, в 22:15, Darin Fisher написал(а):
>
> > I think it makes sense to extend ResourceHandle.cpp to access the
> BlobRegistry singleton in order to support blob URLs.
>
>
> The problem I see with adding blob support to Resourc
14.09.2010, в 22:15, Darin Fisher написал(а):
> I think it makes sense to extend ResourceHandle.cpp to access the
> BlobRegistry singleton in order to support blob URLs.
The problem I see with adding blob support to ResourceHandle is that it makes
it too difficult to maintain. It used to be a
On Sep 14, 2010, at 9:58 PM, Jian Li wrote:
> Indeed when I implement BlobResourceHandle, I have taken the range request
> support into consideration and got it work. The problem is that current media
> element implementation does not route through ResourceHandle.
>
> However, introducing a Re
On Tue, Sep 14, 2010 at 10:09 PM, Adam Barth wrote:
> One thing that Maciej suggested in #webkit was to interpose in the
> same way that appcache interposes. One advantage of that approach is
> economy of mechanism.
>
I think we have mostly done this. See BlobRegistry.
>
> (By the way, round
I think it makes sense to extend ResourceHandle.cpp to access the
BlobRegistry singleton in order to support blob URLs. This will work for
all ports that use ResourceHandle.cpp (everyone except Chromium AFAIK). I
don't think we need to overabstract this.
When designing this system, we took a har
One thing that Maciej suggested in #webkit was to interpose in the
same way that appcache interposes. One advantage of that approach is
economy of mechanism.
(By the way, roundtrips to WebCore are cheap for the WebKit layer;
there isn't much reason to avoid them.)
Adam
On Tue, Sep 14, 2010 at
On Tue, Sep 14, 2010 at 5:52 PM, Maciej Stachowiak wrote:
>
> On Sep 14, 2010, at 5:22 PM, Adam Barth wrote:
>
> >
> > In some sense, this is analogous to adding an HTTPResourceHandle and
> > implementing the HTTP protocol inside of WebCore. While its true that
> > most (all?) users of WebKit wi
Indeed when I implement BlobResourceHandle, I have taken the range request
support into consideration and got it work. The problem is that current
media element implementation does not route through ResourceHandle.
However, introducing a ResourceHandle subclass does not sound like an
elegant solut
On Tue, Sep 14, 2010 at 6:53 PM, Oliver Hunt wrote:
>
> On Sep 14, 2010, at 5:56 PM, David Levin wrote:
>
> On Tue, Sep 14, 2010 at 5:42 PM, Adam Barth wrote:
>
>> What do you think of the idea of having a re-useable BlobCore module
>> that all the ports can share?
>>
>
> I don't think this is a
On Sep 14, 2010, at 5:56 PM, David Levin wrote:
> On Tue, Sep 14, 2010 at 5:42 PM, Adam Barth wrote:
> What do you think of the idea of having a re-useable BlobCore module
> that all the ports can share?
>
> I don't think this is a good idea. This "re-usable module" would only be used
> by the
On Sep 14, 2010, at 6:02 PM, Adam Barth wrote:
> On Tue, Sep 14, 2010 at 5:56 PM, David Levin wrote:
>> On Tue, Sep 14, 2010 at 5:42 PM, Adam Barth wrote:
>>> What do you think of the idea of having a re-useable BlobCore module
>>> that all the ports can share?
>>
>> I don't think this is a go
On Tue, Sep 14, 2010 at 6:02 PM, Adam Barth wrote:
> On Tue, Sep 14, 2010 at 5:56 PM, David Levin wrote:
> > On Tue, Sep 14, 2010 at 5:42 PM, Adam Barth wrote:
> >> What do you think of the idea of having a re-useable BlobCore module
> >> that all the ports can share?
> >
> > I don't think this
On Tue, Sep 14, 2010 at 5:56 PM, David Levin wrote:
> On Tue, Sep 14, 2010 at 5:42 PM, Adam Barth wrote:
>> What do you think of the idea of having a re-useable BlobCore module
>> that all the ports can share?
>
> I don't think this is a good idea. This "re-usable module" would only be
> used by
On Tue, Sep 14, 2010 at 5:42 PM, Adam Barth wrote:
> What do you think of the idea of having a re-useable BlobCore module
> that all the ports can share?
>
I don't think this is a good idea. This "re-usable module" would only be
used by the Safari WebKit port. As I understand it, Chromium wouldn
On Sep 14, 2010, at 5:22 PM, Adam Barth wrote:
>
> In some sense, this is analogous to adding an HTTPResourceHandle and
> implementing the HTTP protocol inside of WebCore. While its true that
> most (all?) users of WebKit will need to wire WebCore up to an HTTP
> library, that doesn't necessari
I think it is a good idea but it will involve lots of work to figure out how
to build and test such module that could be used by all the ports. My
concern is that I do not have enough resource to speak of for all other
ports. Thanks.
On Tue, Sep 14, 2010 at 5:42 PM, Adam Barth wrote:
> What do
What do you think of the idea of having a re-useable BlobCore module
that all the ports can share?
Adam
On Tue, Sep 14, 2010 at 5:39 PM, Jian Li wrote:
> When I implemented the blob scheme handling, I intentionally tried to have
> some common implementation that could be used by all applicable
When I implemented the blob scheme handling, I intentionally tried to have
some common implementation that could be used by all applicable platforms.
But it seems that introducing BlobResourceHandle derived from ResourceHandle
might not be a good hook up point because ResourceHandle is only a wrapp
Jian Li just had a conversation in #webkit about where the code for
implementing the Blob URL scheme should live. I thought I'd open the
discussion to webkit-dev in case folks had a different perspective.
As part of the fileapi, we're introducing a new URL scheme, called
blob, which represents a
27 matches
Mail list logo
