Re: [webkit-dev] Blob scheme implementation

[Darin Fisher]

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:
>>
>>>
>>> 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 platform abstraction,
>>> and it was hard enough to make sure it worked well across platforms. Adding
>>> a significant amount of cross-platform logic on top of that isn't going to
>>> make it easier - especially when it's done via subclassing.
>>>
>>
>> I don't understand why this seems so complicated.  ResourceHandle.cpp
>> contains some code that is shared by all WebKit ports that can access their
>> network stack directly from the WebKit main thread.  It already has some
>> common code for handling certain error cases (invalid URL, bad port).  This
>> is the best point in the code to integrate blob URL support.
>>
>> Maybe subclassing ResourceHandle is not the best way to go about this.  It
>> seems fairly clean to me, but then, I'm not sure what the alternative
>> proposals look like.
>>
>>
>> I posted a proposal yesterday (do it at the ResourceLoader layer, since
>> that's how the app cache hooks in).
>>
>
> That means that app cache doesn't work for HTML5 media in !Chromium.  It
> also means that blob URLs won't work for HTML5 media in !Chromium.
>
>
> Both these things are likely to be true anyway, since most media back ends
> do not even use ResourceHandle. We have a design to fix both of these things
> for the Mac port, and it would not suffer from these features being at the
> ResourceLoader layer.
>
>
>
>>
>>
>>
>>
>>>
>>> An example that prompted me to look into this was <
>>> http://trac.webkit.org/changeset/67503>. Here, a static function that
>>> reported platform capabilities had to become virtual, so that it could take
>>> blob loading logic into account. There is nothing in common between "are we
>>> running on a version of Mac OS X that supports this" and "are we loading a
>>> blob", and remembering this twist won't be easy.
>>>
>>
>> Perhaps the static function should remain but be renamed?  That way it can
>> remain the function that reports platform capabilities.  However, as this
>> patch demonstrates, from WebCore's point of view, this needs to be a
>> property of ResourceHandle.
>>
>> Maybe it would help if we better formalized the abstraction to the network
>> stack and let ResourceHandle grow to be a smart (contains cross-platform
>> helper code) front-end to that.
>>
>>
>> I think that's not the right design. ResourceHandle is supposed to be a
>> thin abstraction on top of the network library. ResourceLoader is supposed
>> to be the "smart" layer.
>>
>>
> I don't see any other examples of URL schemes being handled at the
> ResourceLoader level.
>
>
> Indeed, there aren't any. Most URL schemes do not depend on higher-level
> features of the Web platform. The "blob:" scheme is not quite as magical as
> "javascript:", but it is more magical than "http:".
>
>
> I'm not thrilled to introduce more ways in which Chromium and !Chromium
> differ, but integrating blob URLs at the ResourceLoader is not an option for
> Chromium.
>
>
> Chromium has made some different design choices. Often, following these to
> their logical conclusion leads to designs that look like layering violations
> from the pure WebKit perspective. I sympathize with the need to have a
> design that's viable in the face of a process split. We are certainly
> learning a lot about this as we integrate multiprocess functionality into
> WebKit itself. However, as we do more of this work, I become more skeptical
> that doing multiprocess actually requires quite so many layering violations,
> and so I am hesitant to bend the architecture of WebKit around the desire to
> do things that way.
>
> In fairness, we currently have networking running in the Web process, and
> so have not faced down all of the issues related to I/O living in a separate
> process. However, I am pretty confident that the file I/O needs for Blobs
> can be handled without messing with the ResourceHandle layer, in a way that
> is compatible with sandboxing.
>
> Maybe at some point, a few of us should get together in person to talk
> about the right WebCore-level architecture to support multi-process ports
> while continuing to support a single-process design and with good
> abstractions and layering.
>
> Regards,
> Maciej
>
>

I do think it would be good to have a more in-depth face-to-face discussion
about this topic.

My argument boils down to the following:

1)  It is valuable for downloads to go directly from network stack to file

Re: [webkit-dev] Blob scheme implementation

[Maciej Stachowiak]

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 mold of URL loading.  Mozilla tries
>> to express javascript: URLs as a protocol handler, and it only adds
>> complexity.  The WebKit approach of implementing javascript: URLs as special
>> cases in FrameLoader is superior because it makes the code easier to
>> understand.
> 
> Oh man.  If our JavaScript URL handling is easier to understand than
> Firefox's, I'd be really scared to see theirs.  :)

If you do decide to read it, I promise to visit you regularly at the asylum.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[Maciej Stachowiak]

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 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 platform abstraction, 
>> and it was hard enough to make sure it worked well across platforms. Adding 
>> a significant amount of cross-platform logic on top of that isn't going to 
>> make it easier - especially when it's done via subclassing.
>> 
>> I don't understand why this seems so complicated.  ResourceHandle.cpp 
>> contains some code that is shared by all WebKit ports that can access their 
>> network stack directly from the WebKit main thread.  It already has some 
>> common code for handling certain error cases (invalid URL, bad port).  This 
>> is the best point in the code to integrate blob URL support.
>> 
>> Maybe subclassing ResourceHandle is not the best way to go about this.  It 
>> seems fairly clean to me, but then, I'm not sure what the alternative 
>> proposals look like.
> 
> I posted a proposal yesterday (do it at the ResourceLoader layer, since 
> that's how the app cache hooks in).
> 
> That means that app cache doesn't work for HTML5 media in !Chromium.  It also 
> means that blob URLs won't work for HTML5 media in !Chromium.

Both these things are likely to be true anyway, since most media back ends do 
not even use ResourceHandle. We have a design to fix both of these things for 
the Mac port, and it would not suffer from these features being at the 
ResourceLoader layer.

>  
> 
>> 
>>  
>> 
>> An example that prompted me to look into this was 
>> . Here, a static function that 
>> reported platform capabilities had to become virtual, so that it could take 
>> blob loading logic into account. There is nothing in common between "are we 
>> running on a version of Mac OS X that supports this" and "are we loading a 
>> blob", and remembering this twist won't be easy.
>> 
>> Perhaps the static function should remain but be renamed?  That way it can 
>> remain the function that reports platform capabilities.  However, as this 
>> patch demonstrates, from WebCore's point of view, this needs to be a 
>> property of ResourceHandle.
>> 
>> Maybe it would help if we better formalized the abstraction to the network 
>> stack and let ResourceHandle grow to be a smart (contains cross-platform 
>> helper code) front-end to that.
> 
> I think that's not the right design. ResourceHandle is supposed to be a thin 
> abstraction on top of the network library. ResourceLoader is supposed to be 
> the "smart" layer.
> 
> 
> I don't see any other examples of URL schemes being handled at the 
> ResourceLoader level.

Indeed, there aren't any. Most URL schemes do not depend on higher-level 
features of the Web platform. The "blob:" scheme is not quite as magical as 
"javascript:", but it is more magical than "http:".

> 
> I'm not thrilled to introduce more ways in which Chromium and !Chromium 
> differ, but integrating blob URLs at the ResourceLoader is not an option for 
> Chromium.

Chromium has made some different design choices. Often, following these to 
their logical conclusion leads to designs that look like layering violations 
from the pure WebKit perspective. I sympathize with the need to have a design 
that's viable in the face of a process split. We are certainly learning a lot 
about this as we integrate multiprocess functionality into WebKit itself. 
However, as we do more of this work, I become more skeptical that doing 
multiprocess actually requires quite so many layering violations, and so I am 
hesitant to bend the architecture of WebKit around the desire to do things that 
way.

In fairness, we currently have networking running in the Web process, and so 
have not faced down all of the issues related to I/O living in a separate 
process. However, I am pretty confident that the file I/O needs for Blobs can 
be handled without messing with the ResourceHandle layer, in a way that is 
compatible with sandboxing.

Maybe at some point, a few of us should get together in person to talk about 
the right WebCore-level architecture to support multi-process ports while 
continuing to support a single-process design and with good abstractions and 
layering.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[Adam Barth]

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 javascript: URLs as a protocol handler, and it only adds
> complexity.  The WebKit approach of implementing javascript: URLs as special
> cases in FrameLoader is superior because it makes the code easier to
> understand.

Oh man.  If our JavaScript URL handling is easier to understand than
Firefox's, I'd be really scared to see theirs.  :)

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[Michael Nordman]

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 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 platform abstraction,
>> and it was hard enough to make sure it worked well across platforms. Adding
>> a significant amount of cross-platform logic on top of that isn't going to
>> make it easier - especially when it's done via subclassing.
>>
>
> I don't understand why this seems so complicated.  ResourceHandle.cpp
> contains some code that is shared by all WebKit ports that can access their
> network stack directly from the WebKit main thread.  It already has some
> common code for handling certain error cases (invalid URL, bad port).  This
> is the best point in the code to integrate blob URL support.
>
> Maybe subclassing ResourceHandle is not the best way to go about this.  It
> seems fairly clean to me, but then, I'm not sure what the alternative
> proposals look like.
>
>
>
>>
>> An example that prompted me to look into this was <
>> http://trac.webkit.org/changeset/67503>. Here, a static function that
>> reported platform capabilities had to become virtual, so that it could take
>> blob loading logic into account. There is nothing in common between "are we
>> running on a version of Mac OS X that supports this" and "are we loading a
>> blob", and remembering this twist won't be easy.
>>
>
> Perhaps the static function should remain but be renamed?  That way it can
> remain the function that reports platform capabilities.  However, as this
> patch demonstrates, from WebCore's point of view, this needs to be a
> property of ResourceHandle.
>
> Maybe it would help if we better formalized the abstraction to the network
> stack and let ResourceHandle grow to be a smart (contains cross-platform
> helper code) front-end to that.
>

+1 "Maybe it would help if we better formalized the abstraction to the
network stack and let ResourceHandle grow to be a smart (contains
cross-platform helper code) front-end to that."

AppCache loading has been mentioned a couple times in this thread. Really,
the points of integration between the loader and the appcache are mostly
smoke and mirrors in chrome... loading out of an appcache actually happens
via ResourceHandle in our port. Webcore's webarchive loading wouldn't work
in a sandboxed renderer either.

I'm working up to a similar 'where to put what code' conundrum around
xhr.responseBlob. Ideally, I'd like ResourceHandle to produce the blob.

ResourceHandle vs PlatformResourceHandle, maybe a class like the latter
could have a 'capabilities' interface that allowed common code to query
things like 'CanProvideResponseBlobs' and if not provides that capability in
common code. Similarly a 'CanHandleBlobScheme' capability query could
provide a fork in the road for loading blob urls (so the common code impl
would poke at the BlobRegistry singleton).

Subclassing ResourceHandle for blob url loading is probably not the most
elegant thing, but given the current state of the code base,  it's not a bad
option.

This schism around ResourceHandle in particular is a recurring theme. The
recurring answer "do it in the loader" just doesn't work so well for us.


>
> -Darin
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[Darin Fisher]

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 написал(а):
>>>
>>> > 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 platform abstraction,
>>> and it was hard enough to make sure it worked well across platforms. Adding
>>> a significant amount of cross-platform logic on top of that isn't going to
>>> make it easier - especially when it's done via subclassing.
>>>
>>
>> I don't understand why this seems so complicated.  ResourceHandle.cpp
>> contains some code that is shared by all WebKit ports that can access their
>> network stack directly from the WebKit main thread.  It already has some
>> common code for handling certain error cases (invalid URL, bad port).  This
>> is the best point in the code to integrate blob URL support.
>>
>> Maybe subclassing ResourceHandle is not the best way to go about this.  It
>> seems fairly clean to me, but then, I'm not sure what the alternative
>> proposals look like.
>>
>>
>> I posted a proposal yesterday (do it at the ResourceLoader layer, since
>> that's how the app cache hooks in).
>>
>
> That means that app cache doesn't work for HTML5 media in !Chromium.  It
> also means that blob URLs won't work for HTML5 media in !Chromium.
>
>
>>
>>
>>
>>
>>>
>>> An example that prompted me to look into this was <
>>> http://trac.webkit.org/changeset/67503>. Here, a static function that
>>> reported platform capabilities had to become virtual, so that it could take
>>> blob loading logic into account. There is nothing in common between "are we
>>> running on a version of Mac OS X that supports this" and "are we loading a
>>> blob", and remembering this twist won't be easy.
>>>
>>
>> Perhaps the static function should remain but be renamed?  That way it can
>> remain the function that reports platform capabilities.  However, as this
>> patch demonstrates, from WebCore's point of view, this needs to be a
>> property of ResourceHandle.
>>
>> Maybe it would help if we better formalized the abstraction to the network
>> stack and let ResourceHandle grow to be a smart (contains cross-platform
>> helper code) front-end to that.
>>
>>
>> I think that's not the right design. ResourceHandle is supposed to be a
>> thin abstraction on top of the network library. ResourceLoader is supposed
>> to be the "smart" layer.
>>
>>
> I don't see any other examples of URL schemes being handled at the
> ResourceLoader level.
>

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 javascript: URLs as a protocol handler, and it only adds
complexity.  The WebKit approach of implementing javascript: URLs as special
cases in FrameLoader is superior because it makes the code easier to
understand.

-Darin


>
> I'm not thrilled to introduce more ways in which Chromium and !Chromium
> differ, but integrating blob URLs at the ResourceLoader is not an option for
> Chromium.
>
> -Darin
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[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 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 platform abstraction,
>> and it was hard enough to make sure it worked well across platforms. Adding
>> a significant amount of cross-platform logic on top of that isn't going to
>> make it easier - especially when it's done via subclassing.
>>
>
> I don't understand why this seems so complicated.  ResourceHandle.cpp
> contains some code that is shared by all WebKit ports that can access their
> network stack directly from the WebKit main thread.  It already has some
> common code for handling certain error cases (invalid URL, bad port).  This
> is the best point in the code to integrate blob URL support.
>
> Maybe subclassing ResourceHandle is not the best way to go about this.  It
> seems fairly clean to me, but then, I'm not sure what the alternative
> proposals look like.
>
>
> I posted a proposal yesterday (do it at the ResourceLoader layer, since
> that's how the app cache hooks in).
>

That means that app cache doesn't work for HTML5 media in !Chromium.  It
also means that blob URLs won't work for HTML5 media in !Chromium.


>
>
>
>
>>
>> An example that prompted me to look into this was <
>> http://trac.webkit.org/changeset/67503>. Here, a static function that
>> reported platform capabilities had to become virtual, so that it could take
>> blob loading logic into account. There is nothing in common between "are we
>> running on a version of Mac OS X that supports this" and "are we loading a
>> blob", and remembering this twist won't be easy.
>>
>
> Perhaps the static function should remain but be renamed?  That way it can
> remain the function that reports platform capabilities.  However, as this
> patch demonstrates, from WebCore's point of view, this needs to be a
> property of ResourceHandle.
>
> Maybe it would help if we better formalized the abstraction to the network
> stack and let ResourceHandle grow to be a smart (contains cross-platform
> helper code) front-end to that.
>
>
> I think that's not the right design. ResourceHandle is supposed to be a
> thin abstraction on top of the network library. ResourceLoader is supposed
> to be the "smart" layer.
>
>
I don't see any other examples of URL schemes being handled at the
ResourceLoader level.

I'm not thrilled to introduce more ways in which Chromium and !Chromium
differ, but integrating blob URLs at the ResourceLoader is not an option for
Chromium.

-Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[Maciej Stachowiak]

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.
> 
> 
> The problem I see with adding blob support to ResourceHandle is that it makes 
> it too difficult to maintain. It used to be a platform abstraction, and it 
> was hard enough to make sure it worked well across platforms. Adding a 
> significant amount of cross-platform logic on top of that isn't going to make 
> it easier - especially when it's done via subclassing.
> 
> I don't understand why this seems so complicated.  ResourceHandle.cpp 
> contains some code that is shared by all WebKit ports that can access their 
> network stack directly from the WebKit main thread.  It already has some 
> common code for handling certain error cases (invalid URL, bad port).  This 
> is the best point in the code to integrate blob URL support.
> 
> Maybe subclassing ResourceHandle is not the best way to go about this.  It 
> seems fairly clean to me, but then, I'm not sure what the alternative 
> proposals look like.

I posted a proposal yesterday (do it at the ResourceLoader layer, since that's 
how the app cache hooks in).

> 
>  
> 
> An example that prompted me to look into this was 
> . Here, a static function that 
> reported platform capabilities had to become virtual, so that it could take 
> blob loading logic into account. There is nothing in common between "are we 
> running on a version of Mac OS X that supports this" and "are we loading a 
> blob", and remembering this twist won't be easy.
> 
> Perhaps the static function should remain but be renamed?  That way it can 
> remain the function that reports platform capabilities.  However, as this 
> patch demonstrates, from WebCore's point of view, this needs to be a property 
> of ResourceHandle.
> 
> Maybe it would help if we better formalized the abstraction to the network 
> stack and let ResourceHandle grow to be a smart (contains cross-platform 
> helper code) front-end to that.

I think that's not the right design. ResourceHandle is supposed to be a thin 
abstraction on top of the network library. ResourceLoader is supposed to be the 
"smart" layer.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[Darin Fisher]

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 ResourceHandle is that it
> makes it too difficult to maintain. It used to be a platform abstraction,
> and it was hard enough to make sure it worked well across platforms. Adding
> a significant amount of cross-platform logic on top of that isn't going to
> make it easier - especially when it's done via subclassing.
>

I don't understand why this seems so complicated.  ResourceHandle.cpp
contains some code that is shared by all WebKit ports that can access their
network stack directly from the WebKit main thread.  It already has some
common code for handling certain error cases (invalid URL, bad port).  This
is the best point in the code to integrate blob URL support.

Maybe subclassing ResourceHandle is not the best way to go about this.  It
seems fairly clean to me, but then, I'm not sure what the alternative
proposals look like.



>
> An example that prompted me to look into this was <
> http://trac.webkit.org/changeset/67503>. Here, a static function that
> reported platform capabilities had to become virtual, so that it could take
> blob loading logic into account. There is nothing in common between "are we
> running on a version of Mac OS X that supports this" and "are we loading a
> blob", and remembering this twist won't be easy.
>

Perhaps the static function should remain but be renamed?  That way it can
remain the function that reports platform capabilities.  However, as this
patch demonstrates, from WebCore's point of view, this needs to be a
property of ResourceHandle.

Maybe it would help if we better formalized the abstraction to the network
stack and let ResourceHandle grow to be a smart (contains cross-platform
helper code) front-end to that.

-Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[Alexey Proskuryakov]

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 platform abstraction, and it was 
hard enough to make sure it worked well across platforms. Adding a significant 
amount of cross-platform logic on top of that isn't going to make it easier - 
especially when it's done via subclassing.

An example that prompted me to look into this was 
. Here, a static function that reported 
platform capabilities had to become virtual, so that it could take blob loading 
logic into account. There is nothing in common between "are we running on a 
version of Mac OS X that supports this" and "are we loading a blob", and 
remembering this twist won't be easy.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[Maciej Stachowiak]

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 ResourceHandle subclass does not sound like an elegant 
> solution given that ResoucreHandle is currently treated as a wrapper class to 
> the underlying platform implementation. I agree it would be better if we 
> could find a way to avoid extra roundtrip to pop back to WebCore to do the 
> real handling. But I am not sure how this could be hooked up. The handling of 
> javascript: url is somewhat special. Probably we cannot do the similar thing 
> as it since the handling of blob: url needs to work closely with resource 
> loader and caching layer so that we can get it work in all scenarios.
> 
> Do you have any good suggestion on what is the right layer to hook into? Does 
> it make sense if I move the current implementation of BlobResourceHandle to 
> the underlying platform layer for WebKit mac so that I can fix the issue with 
> incorrect subclassing of ResourceHandle?

Subclassing ResourceHandle is somewhat inelegant. It's not a class designed to 
be subclassed, and subclassing it correctly probably requires making more 
methods virtual. In addition, since the blob: URL scheme implementation needs 
to know about other parts of WebCore outside the platform/ directory, it's a 
bit of a layering violation to have a ResouceHandle subclass dealing with it.

One (maybe slightly odd) thought that came to me is that perhaps blob: can be 
handled at the ResourceLoader level. That is the level where higher-level 
concepts are allowed to take over the load - for example, app cache hooks in at 
this layer, as does WebArchive loading, and also the ability to load a premade 
data chunk as a web page instead of loading an actual URL. So in that regard, 
it's a natural place for higher-level Web platform concepts to take over the 
load. This would be different from the way we handle any other URL scheme, but 
one way or another, blob: needs to be special, so maybe that's ok.

Regards,
Maciej


> 
> On Tue, Sep 14, 2010 at 6:21 PM, Maciej Stachowiak  wrote:
> 
> 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 good idea. This "re-usable module" would only be
> >> used by the Safari WebKit port. As I understand it, Chromium wouldn't be
> >> able to re-use it due to not re-using WebKit types in general. With only 
> >> one
> >> port using it, the module seems like it would not be able to have a good
> >> design.
> >>
> >> So if there is a change, it seems better to just write it for the Safari
> >> WebKit port and as other ports want to implement it, if they find
> >> commonality, it would be in their best interest to refractor the existing
> >> code for better re-use.
> >
> > Would Chromium be able to re-use the code if it were part of WebCore?
> > I guess I don't understand what's different about those two cases.
> >
> > Another question, does this design allow blob URLs to be used by the
> >  element?  My understanding is that  bypasses
> > ResourceHandle because ResourceHandle isn't smart enough to handle
> > range requests (or something like that).
> 
> At least on Mac, the media elements miss out on a number of networking 
> features due to not going through the CachedResource layer and those below. 
> For example they don't work with the app cache. It's something we'd like to 
> fix eventually.
> 
> Note: ResourceHandle would probably work and can handle range requests fine, 
> but the media APIs on Mac make it tricky to fully replace the loading that 
> the media framework likes to do for itself. If we had that, we could hook up 
> ResourceHandle pretty easily. The cache layer would need to be enhanced to 
> handle ranges though.
> 
> Regards,
> Maciej
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[Darin Fisher]

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, roundtrips to WebCore are cheap for the WebKit layer;
> there isn't much reason to avoid them.)
>
>
If you are referring to using Chromium's WebKit API from Chromium's browser
process, keep in mind that that really has to be done from the
in-process-webkit thread.  However, we want to handle URL requests on the IO
thread.  Having to proxy threads for this would be both cumbersome and add
undesirable latency to URL loading.  (I have data indicating that such a
thread hop is costly for loading local files.)

-Darin



> Adam
>
>
> On Tue, 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 ResourceHandle subclass does not sound like an
> > elegant solution given that ResoucreHandle is currently treated as a
> wrapper
> > class to the underlying platform implementation. I agree it would be
> better
> > if we could find a way to avoid extra roundtrip to pop back to WebCore to
> do
> > the real handling. But I am not sure how this could be hooked up. The
> > handling of javascript: url is somewhat special. Probably we cannot do
> the
> > similar thing as it since the handling of blob: url needs to work closely
> > with resource loader and caching layer so that we can get it work in all
> > scenarios.
> > Do you have any good suggestion on what is the right layer to hook into?
> > Does it make sense if I move the current implementation of
> > BlobResourceHandle to the underlying platform layer for WebKit mac so
> that I
> > can fix the issue with incorrect subclassing of ResourceHandle?
> > On Tue, Sep 14, 2010 at 6:21 PM, Maciej Stachowiak 
> wrote:
> >>
> >> 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 good idea. This "re-usable module" would only
> >> >> be
> >> >> used by the Safari WebKit port. As I understand it, Chromium wouldn't
> >> >> be
> >> >> able to re-use it due to not re-using WebKit types in general. With
> >> >> only one
> >> >> port using it, the module seems like it would not be able to have a
> >> >> good
> >> >> design.
> >> >>
> >> >> So if there is a change, it seems better to just write it for the
> >> >> Safari
> >> >> WebKit port and as other ports want to implement it, if they find
> >> >> commonality, it would be in their best interest to refractor the
> >> >> existing
> >> >> code for better re-use.
> >> >
> >> > Would Chromium be able to re-use the code if it were part of WebCore?
> >> > I guess I don't understand what's different about those two cases.
> >> >
> >> > Another question, does this design allow blob URLs to be used by the
> >> >  element?  My understanding is that  bypasses
> >> > ResourceHandle because ResourceHandle isn't smart enough to handle
> >> > range requests (or something like that).
> >>
> >> At least on Mac, the media elements miss out on a number of networking
> >> features due to not going through the CachedResource layer and those
> below.
> >> For example they don't work with the app cache. It's something we'd like
> to
> >> fix eventually.
> >>
> >> Note: ResourceHandle would probably work and can handle range requests
> >> fine, but the media APIs on Mac make it tricky to fully replace the
> loading
> >> that the media framework likes to do for itself. If we had that, we
> could
> >> hook up ResourceHandle pretty easily. The cache layer would need to be
> >> enhanced to handle ranges though.
> >>
> >> Regards,
> >> Maciej
> >>
> >> ___
> >> webkit-dev mailing list
> >> webkit-dev@lists.webkit.org
> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[Darin Fisher]

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 hard look at how we could make
Chromium reuse a WebCore implementation of  BlobRegistry and
BlobResourceHandle, but it just isn't a good match for Chromium's network
stack.  We need to subclass URLRequestJob (defined in Chromium's network
stack), and it would just be a big mess to convert between WebCore types and
Chromium types.  The amount of code that could be shared would be so small
that it just didn't seem worth it.

-Darin

On Tue, 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 ResourceHandle subclass does not sound like an
> elegant solution given that ResoucreHandle is currently treated as a wrapper
> class to the underlying platform implementation. I agree it would be better
> if we could find a way to avoid extra roundtrip to pop back to WebCore to do
> the real handling. But I am not sure how this could be hooked up. The
> handling of javascript: url is somewhat special. Probably we cannot do the
> similar thing as it since the handling of blob: url needs to work closely
> with resource loader and caching layer so that we can get it work in all
> scenarios.
>
> Do you have any good suggestion on what is the right layer to hook into?
> Does it make sense if I move the current implementation of
> BlobResourceHandle to the underlying platform layer for WebKit mac so that I
> can fix the issue with incorrect subclassing of ResourceHandle?
>
> On Tue, Sep 14, 2010 at 6:21 PM, Maciej Stachowiak  wrote:
>
>>
>> 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 good idea. This "re-usable module" would only
>> be
>> >> used by the Safari WebKit port. As I understand it, Chromium wouldn't
>> be
>> >> able to re-use it due to not re-using WebKit types in general. With
>> only one
>> >> port using it, the module seems like it would not be able to have a
>> good
>> >> design.
>> >>
>> >> So if there is a change, it seems better to just write it for the
>> Safari
>> >> WebKit port and as other ports want to implement it, if they find
>> >> commonality, it would be in their best interest to refractor the
>> existing
>> >> code for better re-use.
>> >
>> > Would Chromium be able to re-use the code if it were part of WebCore?
>> > I guess I don't understand what's different about those two cases.
>> >
>> > Another question, does this design allow blob URLs to be used by the
>> >  element?  My understanding is that  bypasses
>> > ResourceHandle because ResourceHandle isn't smart enough to handle
>> > range requests (or something like that).
>>
>> At least on Mac, the media elements miss out on a number of networking
>> features due to not going through the CachedResource layer and those below.
>> For example they don't work with the app cache. It's something we'd like to
>> fix eventually.
>>
>> Note: ResourceHandle would probably work and can handle range requests
>> fine, but the media APIs on Mac make it tricky to fully replace the loading
>> that the media framework likes to do for itself. If we had that, we could
>> hook up ResourceHandle pretty easily. The cache layer would need to be
>> enhanced to handle ranges though.
>>
>> Regards,
>> Maciej
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[Adam Barth]

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 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 ResourceHandle subclass does not sound like an
> elegant solution given that ResoucreHandle is currently treated as a wrapper
> class to the underlying platform implementation. I agree it would be better
> if we could find a way to avoid extra roundtrip to pop back to WebCore to do
> the real handling. But I am not sure how this could be hooked up. The
> handling of javascript: url is somewhat special. Probably we cannot do the
> similar thing as it since the handling of blob: url needs to work closely
> with resource loader and caching layer so that we can get it work in all
> scenarios.
> Do you have any good suggestion on what is the right layer to hook into?
> Does it make sense if I move the current implementation of
> BlobResourceHandle to the underlying platform layer for WebKit mac so that I
> can fix the issue with incorrect subclassing of ResourceHandle?
> On Tue, Sep 14, 2010 at 6:21 PM, Maciej Stachowiak  wrote:
>>
>> 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 good idea. This "re-usable module" would only
>> >> be
>> >> used by the Safari WebKit port. As I understand it, Chromium wouldn't
>> >> be
>> >> able to re-use it due to not re-using WebKit types in general. With
>> >> only one
>> >> port using it, the module seems like it would not be able to have a
>> >> good
>> >> design.
>> >>
>> >> So if there is a change, it seems better to just write it for the
>> >> Safari
>> >> WebKit port and as other ports want to implement it, if they find
>> >> commonality, it would be in their best interest to refractor the
>> >> existing
>> >> code for better re-use.
>> >
>> > Would Chromium be able to re-use the code if it were part of WebCore?
>> > I guess I don't understand what's different about those two cases.
>> >
>> > Another question, does this design allow blob URLs to be used by the
>> >  element?  My understanding is that  bypasses
>> > ResourceHandle because ResourceHandle isn't smart enough to handle
>> > range requests (or something like that).
>>
>> At least on Mac, the media elements miss out on a number of networking
>> features due to not going through the CachedResource layer and those below.
>> For example they don't work with the app cache. It's something we'd like to
>> fix eventually.
>>
>> Note: ResourceHandle would probably work and can handle range requests
>> fine, but the media APIs on Mac make it tricky to fully replace the loading
>> that the media framework likes to do for itself. If we had that, we could
>> hook up ResourceHandle pretty easily. The cache layer would need to be
>> enhanced to handle ranges though.
>>
>> Regards,
>> Maciej
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[Darin Fisher]

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 will need to wire WebCore up to an HTTP
> > library, that doesn't necessarily mean that WebCore should contain an
> > implementation of the HTTP protocol.  In the same way, even if a large
> > number of WebKit users will wish to support the blob URL scheme, that
> > doesn't necessarily mean that WebCore should contain an implementation
> > of the scheme.
> >
> > I can certainly see the appeal of sharing the blob URL implementation
> > code between different ports of WebKit, but we can achieve that goal
> > in a number of ways, including creating an external library or a
> > separate BlobCore module.
>
> I'm not sure about this. The reason WebKit defers to a port-specific
> library for networking originally stemmed from the desire to integrate with
> existing libraries that might have non-Web clients. While this has some
> benefits, it also has some costs - many aspects of the HTTP stack have
> compatibility impact and so WebKit-based browsers vary more in their
> Web-facing behavior than they would otherwise.
>
> In the case of the blob: scheme, my understanding is that it makes no sense
> outside the browser context, and has tight interactions with other parts of
> the platform - for instance, my understanding is that blob: URLs are not
> permanent but rather may cease to be valid as some point (correct me if I'm
> wrong).
>
> This makes me think that blob: URLs are maybe more like javascript: URLs,
> in that trying to make them part of the network library would actually
> produce layering violations rather than resolving them, and would not in
> practice benefit non-browser clients of those libraries. Threading
> javascript: URLs through the network stack only to pop back to WebCore to do
> the actual processing would be silly. I think maybe blob: is the same way,
> though to a lesser degree.
>
> Regard,
> Maciej
>
>
The key issue, which I think has been touched on elsewhere in this thread,
is HTML5 media.  Since that doesn't use ResourceHandle, it is necessary for
blob URLs to be integrated at a lower level so that the HTML5 media engine
can access them.

There is also another Chromium specific issue:  When downloading an URL in
Chromium, we bypass WebKit.  We avoid streaming data into WebKit only to
redirect it back out of the sandboxed WebKit process.  So we need Chromium
to be able to load URLs from our main process that lives outside of the
sandbox.  This means that the blob URL support needs to be sufficiently
decoupled from WebCore (and behind the ResourceHandle interface).

Finally, I don't think there is a layering violation given the BlobRegistry
interface that Jian has created.  It provides WebCore with an interface to
inform the network layer about blobs.

-Darin


>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[Jian Li]

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 solution given that ResoucreHandle is currently treated as a wrapper
class to the underlying platform implementation. I agree it would be better
if we could find a way to avoid extra roundtrip to pop back to WebCore to do
the real handling. But I am not sure how this could be hooked up. The
handling of javascript: url is somewhat special. Probably we cannot do the
similar thing as it since the handling of blob: url needs to work closely
with resource loader and caching layer so that we can get it work in all
scenarios.

Do you have any good suggestion on what is the right layer to hook into?
Does it make sense if I move the current implementation of
BlobResourceHandle to the underlying platform layer for WebKit mac so that I
can fix the issue with incorrect subclassing of ResourceHandle?

On Tue, Sep 14, 2010 at 6:21 PM, Maciej Stachowiak  wrote:

>
> 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 good idea. This "re-usable module" would only be
> >> used by the Safari WebKit port. As I understand it, Chromium wouldn't be
> >> able to re-use it due to not re-using WebKit types in general. With only
> one
> >> port using it, the module seems like it would not be able to have a good
> >> design.
> >>
> >> So if there is a change, it seems better to just write it for the Safari
> >> WebKit port and as other ports want to implement it, if they find
> >> commonality, it would be in their best interest to refractor the
> existing
> >> code for better re-use.
> >
> > Would Chromium be able to re-use the code if it were part of WebCore?
> > I guess I don't understand what's different about those two cases.
> >
> > Another question, does this design allow blob URLs to be used by the
> >  element?  My understanding is that  bypasses
> > ResourceHandle because ResourceHandle isn't smart enough to handle
> > range requests (or something like that).
>
> At least on Mac, the media elements miss out on a number of networking
> features due to not going through the CachedResource layer and those below.
> For example they don't work with the app cache. It's something we'd like to
> fix eventually.
>
> Note: ResourceHandle would probably work and can handle range requests
> fine, but the media APIs on Mac make it tricky to fully replace the loading
> that the media framework likes to do for itself. If we had that, we could
> hook up ResourceHandle pretty easily. The cache layer would need to be
> enhanced to handle ranges though.
>
> Regards,
> Maciej
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[David Levin]

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 good idea. This "re-usable module" would only be
> used by the Safari WebKit port. As I understand it, Chromium wouldn't be
> able to re-use it due to not re-using WebKit types in general. With only one
> port using it, the module seems like it would not be able to have a good
> design.
>
> What about Gtk, Qt, Wx, Efl...?  Where possible these days we seem to
> implement a single impl in webcore that is used by everyone
>

Indeed, it is a worthy goal. In fact, the current implementation does that,
but there were some concerns about how it was accomplished. So Adam's
proposal is to implement a re-usable module which is wired up by each
individual port down in the port's specific implementation by each
platform's maintainers.

I was simply remarking that it doesn't seem good to start out with a
generalization that only one port is using. (In the past when I've done
generalizations of this sort, it tends to be too generic and a lot more
complicated/complex than necessary.)

Instead if the code were just done for WebKit OSX, when a second port starts
to do something, it could break out the code that is generic because that
would result in a design that is done at the right level.

dave


>
> --Oliver
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[Oliver Hunt]

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 Safari WebKit port. As I understand it, Chromium wouldn't be able to 
> re-use it due to not re-using WebKit types in general. With only one port 
> using it, the module seems like it would not be able to have a good design.

What about Gtk, Qt, Wx, Efl...?  Where possible these days we seem to implement 
a single impl in webcore that is used by everyone

--Oliver

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[Maciej Stachowiak]

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 good idea. This "re-usable module" would only be
>> used by the Safari WebKit port. As I understand it, Chromium wouldn't be
>> able to re-use it due to not re-using WebKit types in general. With only one
>> port using it, the module seems like it would not be able to have a good
>> design.
>> 
>> So if there is a change, it seems better to just write it for the Safari
>> WebKit port and as other ports want to implement it, if they find
>> commonality, it would be in their best interest to refractor the existing
>> code for better re-use.
> 
> Would Chromium be able to re-use the code if it were part of WebCore?
> I guess I don't understand what's different about those two cases.
> 
> Another question, does this design allow blob URLs to be used by the
>  element?  My understanding is that  bypasses
> ResourceHandle because ResourceHandle isn't smart enough to handle
> range requests (or something like that).

At least on Mac, the media elements miss out on a number of networking features 
due to not going through the CachedResource layer and those below. For example 
they don't work with the app cache. It's something we'd like to fix eventually.

Note: ResourceHandle would probably work and can handle range requests fine, 
but the media APIs on Mac make it tricky to fully replace the loading that the 
media framework likes to do for itself. If we had that, we could hook up 
ResourceHandle pretty easily. The cache layer would need to be enhanced to 
handle ranges though.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[Jian Li]

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 is a good idea. This "re-usable module" would only be
> > used by the Safari WebKit port. As I understand it, Chromium wouldn't be
> > able to re-use it due to not re-using WebKit types in general. With only
> one
> > port using it, the module seems like it would not be able to have a good
> > design.
> >
> > So if there is a change, it seems better to just write it for the Safari
> > WebKit port and as other ports want to implement it, if they find
> > commonality, it would be in their best interest to refractor the existing
> > code for better re-use.
>
> Would Chromium be able to re-use the code if it were part of WebCore?
> I guess I don't understand what's different about those two cases.
>

No. As David said, one reason is to avoid incurring the unnecessary cost of
converting between WebCore type data and Chromium type data.

>
> Another question, does this design allow blob URLs to be used by the
>  element?  My understanding is that  bypasses
> ResourceHandle because ResourceHandle isn't smart enough to handle
> range requests (or something like that).
>
> Unfortunately it does not work for video elements since they're loaded in
different code path.


> Adam
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[Adam Barth]

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 the Safari WebKit port. As I understand it, Chromium wouldn't be
> able to re-use it due to not re-using WebKit types in general. With only one
> port using it, the module seems like it would not be able to have a good
> design.
>
> So if there is a change, it seems better to just write it for the Safari
> WebKit port and as other ports want to implement it, if they find
> commonality, it would be in their best interest to refractor the existing
> code for better re-use.

Would Chromium be able to re-use the code if it were part of WebCore?
I guess I don't understand what's different about those two cases.

Another question, does this design allow blob URLs to be used by the
 element?  My understanding is that  bypasses
ResourceHandle because ResourceHandle isn't smart enough to handle
range requests (or something like that).

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[David Levin]

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't be
able to re-use it due to not re-using WebKit types in general. With only one
port using it, the module seems like it would not be able to have a good
design.

So if there is a change, it seems better to just write it for the Safari
WebKit port and as other ports want to implement it, if they find
commonality, it would be in their best interest to refractor the existing
code for better re-use.

dave



>
> 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
> platforms.
> > But it seems that introducing BlobResourceHandle derived from
> ResourceHandle
> > might not be a good hook up point because ResourceHandle is only a
> wrapper
> > around the platform loading logics.
> > To fix this problem, I can move all the blob handling logic to the
> platform
> > specific layer (for WebKit mac) and it is up to other individual platform
> to
> > implement it when needed.
> > Jian
> >
> > On Tue, Sep 14, 2010 at 5:22 PM, Adam Barth  wrote:
> >>
> >> 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 bucket of bits, usually from a file, but
> >> potentially from another location.  Assigning these objects URL is
> >> helpful because then they integrate with the rest of the web platform.
> >>  For example, you can use them as images via the  element or
> >> videos via the  element, etc.
> >>
> >> Currently, the blob URL scheme is implemented with a subclass of
> >> ResourceHandle (our primary network abstraction) called
> >> BlobResourceHandle.  My sense is that this isn't the right place in
> >> the architecture to add support for the blob URL scheme.  The issue is
> >> that each port has a table somewhere that maps URL schemes to
> >> networking backends.  In Chromium, for example, that mapping is
> >> provided by URLRequestFactory, which lives in the "net" module.  By
> >> implementing the blob URL scheme at the ResourceHandle layer, we're
> >> short-circuiting that table.
> >>
> >> 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 necessarily mean that WebCore should contain an
> >> implementation of the HTTP protocol.  In the same way, even if a large
> >> number of WebKit users will wish to support the blob URL scheme, that
> >> doesn't necessarily mean that WebCore should contain an implementation
> >> of the scheme.
> >>
> >> I can certainly see the appeal of sharing the blob URL implementation
> >> code between different ports of WebKit, but we can achieve that goal
> >> in a number of ways, including creating an external library or a
> >> separate BlobCore module.
> >>
> >> Adam
> >
> >
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[Maciej Stachowiak]

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 necessarily mean that WebCore should contain an
> implementation of the HTTP protocol.  In the same way, even if a large
> number of WebKit users will wish to support the blob URL scheme, that
> doesn't necessarily mean that WebCore should contain an implementation
> of the scheme.
> 
> I can certainly see the appeal of sharing the blob URL implementation
> code between different ports of WebKit, but we can achieve that goal
> in a number of ways, including creating an external library or a
> separate BlobCore module.

I'm not sure about this. The reason WebKit defers to a port-specific library 
for networking originally stemmed from the desire to integrate with existing 
libraries that might have non-Web clients. While this has some benefits, it 
also has some costs - many aspects of the HTTP stack have compatibility impact 
and so WebKit-based browsers vary more in their Web-facing behavior than they 
would otherwise.

In the case of the blob: scheme, my understanding is that it makes no sense 
outside the browser context, and has tight interactions with other parts of the 
platform - for instance, my understanding is that blob: URLs are not permanent 
but rather may cease to be valid as some point (correct me if I'm wrong).

This makes me think that blob: URLs are maybe more like javascript: URLs, in 
that trying to make them part of the network library would actually produce 
layering violations rather than resolving them, and would not in practice 
benefit non-browser clients of those libraries. Threading javascript: URLs 
through the network stack only to pop back to WebCore to do the actual 
processing would be silly. I think maybe blob: is the same way, though to a 
lesser degree.

Regard,
Maciej




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[Jian Li]

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 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
> platforms.
> > But it seems that introducing BlobResourceHandle derived from
> ResourceHandle
> > might not be a good hook up point because ResourceHandle is only a
> wrapper
> > around the platform loading logics.
> > To fix this problem, I can move all the blob handling logic to the
> platform
> > specific layer (for WebKit mac) and it is up to other individual platform
> to
> > implement it when needed.
> > Jian
> >
> > On Tue, Sep 14, 2010 at 5:22 PM, Adam Barth  wrote:
> >>
> >> 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 bucket of bits, usually from a file, but
> >> potentially from another location.  Assigning these objects URL is
> >> helpful because then they integrate with the rest of the web platform.
> >>  For example, you can use them as images via the  element or
> >> videos via the  element, etc.
> >>
> >> Currently, the blob URL scheme is implemented with a subclass of
> >> ResourceHandle (our primary network abstraction) called
> >> BlobResourceHandle.  My sense is that this isn't the right place in
> >> the architecture to add support for the blob URL scheme.  The issue is
> >> that each port has a table somewhere that maps URL schemes to
> >> networking backends.  In Chromium, for example, that mapping is
> >> provided by URLRequestFactory, which lives in the "net" module.  By
> >> implementing the blob URL scheme at the ResourceHandle layer, we're
> >> short-circuiting that table.
> >>
> >> 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 necessarily mean that WebCore should contain an
> >> implementation of the HTTP protocol.  In the same way, even if a large
> >> number of WebKit users will wish to support the blob URL scheme, that
> >> doesn't necessarily mean that WebCore should contain an implementation
> >> of the scheme.
> >>
> >> I can certainly see the appeal of sharing the blob URL implementation
> >> code between different ports of WebKit, but we can achieve that goal
> >> in a number of ways, including creating an external library or a
> >> separate BlobCore module.
> >>
> >> Adam
> >
> >
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[Adam Barth]

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 platforms.
> But it seems that introducing BlobResourceHandle derived from ResourceHandle
> might not be a good hook up point because ResourceHandle is only a wrapper
> around the platform loading logics.
> To fix this problem, I can move all the blob handling logic to the platform
> specific layer (for WebKit mac) and it is up to other individual platform to
> implement it when needed.
> Jian
>
> On Tue, Sep 14, 2010 at 5:22 PM, Adam Barth  wrote:
>>
>> 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 bucket of bits, usually from a file, but
>> potentially from another location.  Assigning these objects URL is
>> helpful because then they integrate with the rest of the web platform.
>>  For example, you can use them as images via the  element or
>> videos via the  element, etc.
>>
>> Currently, the blob URL scheme is implemented with a subclass of
>> ResourceHandle (our primary network abstraction) called
>> BlobResourceHandle.  My sense is that this isn't the right place in
>> the architecture to add support for the blob URL scheme.  The issue is
>> that each port has a table somewhere that maps URL schemes to
>> networking backends.  In Chromium, for example, that mapping is
>> provided by URLRequestFactory, which lives in the "net" module.  By
>> implementing the blob URL scheme at the ResourceHandle layer, we're
>> short-circuiting that table.
>>
>> 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 necessarily mean that WebCore should contain an
>> implementation of the HTTP protocol.  In the same way, even if a large
>> number of WebKit users will wish to support the blob URL scheme, that
>> doesn't necessarily mean that WebCore should contain an implementation
>> of the scheme.
>>
>> I can certainly see the appeal of sharing the blob URL implementation
>> code between different ports of WebKit, but we can achieve that goal
>> in a number of ways, including creating an external library or a
>> separate BlobCore module.
>>
>> Adam
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

[Jian Li]

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 wrapper
around the platform loading logics.

To fix this problem, I can move all the blob handling logic to the platform
specific layer (for WebKit mac) and it is up to other individual platform to
implement it when needed.

Jian


On Tue, Sep 14, 2010 at 5:22 PM, Adam Barth  wrote:

> 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 bucket of bits, usually from a file, but
> potentially from another location.  Assigning these objects URL is
> helpful because then they integrate with the rest of the web platform.
>  For example, you can use them as images via the  element or
> videos via the  element, etc.
>
> Currently, the blob URL scheme is implemented with a subclass of
> ResourceHandle (our primary network abstraction) called
> BlobResourceHandle.  My sense is that this isn't the right place in
> the architecture to add support for the blob URL scheme.  The issue is
> that each port has a table somewhere that maps URL schemes to
> networking backends.  In Chromium, for example, that mapping is
> provided by URLRequestFactory, which lives in the "net" module.  By
> implementing the blob URL scheme at the ResourceHandle layer, we're
> short-circuiting that table.
>
> 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 necessarily mean that WebCore should contain an
> implementation of the HTTP protocol.  In the same way, even if a large
> number of WebKit users will wish to support the blob URL scheme, that
> doesn't necessarily mean that WebCore should contain an implementation
> of the scheme.
>
> I can certainly see the appeal of sharing the blob URL implementation
> code between different ports of WebKit, but we can achieve that goal
> in a number of ways, including creating an external library or a
> separate BlobCore module.
>
> Adam
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Blob scheme implementation

[Adam Barth]

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 bucket of bits, usually from a file, but
potentially from another location.  Assigning these objects URL is
helpful because then they integrate with the rest of the web platform.
 For example, you can use them as images via the  element or
videos via the  element, etc.

Currently, the blob URL scheme is implemented with a subclass of
ResourceHandle (our primary network abstraction) called
BlobResourceHandle.  My sense is that this isn't the right place in
the architecture to add support for the blob URL scheme.  The issue is
that each port has a table somewhere that maps URL schemes to
networking backends.  In Chromium, for example, that mapping is
provided by URLRequestFactory, which lives in the "net" module.  By
implementing the blob URL scheme at the ResourceHandle layer, we're
short-circuiting that table.

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 necessarily mean that WebCore should contain an
implementation of the HTTP protocol.  In the same way, even if a large
number of WebKit users will wish to support the blob URL scheme, that
doesn't necessarily mean that WebCore should contain an implementation
of the scheme.

I can certainly see the appeal of sharing the blob URL implementation
code between different ports of WebKit, but we can achieve that goal
in a number of ways, including creating an external library or a
separate BlobCore module.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev