Re: [webkit-dev] XHR responseArrayBuffer attribute

2010-09-28 Thread Chris Marrin

On Sep 27, 2010, at 6:37 PM, Maciej Stachowiak wrote:

 
 On Sep 27, 2010, at 3:19 PM, Michael Nordman wrote:
 
 Webkit's XHR currently does not keep two copies of the data that I can see. 
 I think we should avoid that.
 
 We could keep the raw data around, which hopefully is directly usable as an 
 ArrayBuffer backing store, and only translate it to text format when/if the 
 client requests responseText. 

Yes, the raw data should be usable without translation in an ArrayBuffer. But 
we'd still need to make a copy of the raw bits when a new ArrayBuffer is 
created via responseArrayBuffer(), because that object is mutable.

-
~Chris
cmar...@apple.com




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


Re: [webkit-dev] XHR responseArrayBuffer attribute

2010-09-28 Thread Chris Marrin

On Sep 27, 2010, at 6:40 PM, James Robinson wrote:

 On Mon, Sep 27, 2010 at 6:37 PM, Maciej Stachowiak m...@apple.com wrote:
 
 On Sep 27, 2010, at 3:19 PM, Michael Nordman wrote:
 
 Webkit's XHR currently does not keep two copies of the data that I can see. 
 I think we should avoid that.
 
 We could keep the raw data around, which hopefully is directly usable as an 
 ArrayBuffer backing store, and only translate it to text format when/if the 
 client requests responseText. 
 
 
 It would be unfortunate to have to keep the raw data around after the page 
 access .responseText, given that the overwhelming majority of pages will 
 touch .responseText and nothing else.  I found when improving the V8 XHR 
 implementation that the memory footprint of .responseText being held off of 
 the XHR object itself was often significant so I would be very reluctant to 
 grow it by an addition 50-100% (depending on encoding) in the common case.

But do you think you'd ever need more than one copy of the raw bits from the 
response? Seems like you should be able to return a responseText and a 
responseArrayBuffer from the same raw bits. Am I missing some detail of how XHR 
works?

-
~Chris
cmar...@apple.com




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


Re: [webkit-dev] X-Purpose on prefetching requests

2010-09-28 Thread 蓋文彼德斯
Noone has commented on this thread in some time; is this less controversial now?

On 24 September 2010 21:27, Alexey Proskuryakov a...@webkit.org wrote:

 Eric has made another good point in Bugzilla - we don't explain the purpose 
 in lots of other cases, from loading into a display:none frame to 
 XMLHttpRequest. Why should Prefetch be all the different?


Those requests are still part of loading a page as requested by the
user, and failing them or returning a 500 will result in undefined
behaviour; the result of failing part of a page is unpredictable.

In the case of prefetches, we're in a very different space.  The
prefetch load has no effects on the DOM of the current resource
(unlike display:none elements).  There is no javascript event, or
history impact, etc... (unlike XMLHttpRequest).   A subsequent
navigation will occur correctly whether there was no prefetch, a
prefetch that failed, a prefetch that requires revalidation, and a
prefetch that can be used without revalidation.

So that, in my mind, leaves the balance in favour of emitting the
header, as Mozilla  Safari currently do in similar situations.

Thoughts?

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


Re: [webkit-dev] X-Purpose on prefetching requests

2010-09-28 Thread Alexey Proskuryakov

28.09.2010, в 07:58, Gavin Peters (蓋文彼德斯) написал(а):

 Noone has commented on this thread in some time; is this less controversial 
 now?


I've presented some concerns about the effect of this on enterprise network 
monitors.

It it also not really clear what the benefits of the proposed approach are. 
It's beginning to sound like this header doesn't even help statistics much, and 
the only practical use is refusing to serve a request under high load. But I 
suspect that there is not much difference between returning a 5xx response and 
serving a cached pseudo-static version of a resource. It should be much easier 
to implement the latter (which lots of servers obviously already do) than to 
change behavior based on current load.

- WBR, Alexey Proskuryakov

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


Re: [webkit-dev] X-Purpose on prefetching requests

2010-09-28 Thread 蓋文彼德斯
On 28 September 2010 11:58, Alexey Proskuryakov a...@webkit.org wrote:

 28.09.2010, в 07:58, Gavin Peters (蓋文彼德斯) написал(а):

 Noone has commented on this thread in some time; is this less controversial 
 now?


 I've presented some concerns about the effect of this on enterprise network 
 monitors.

 It it also not really clear what the benefits of the proposed approach are. 
 It's beginning to sound like this header doesn't even help statistics much, 
 and the only practical use is refusing to serve a request under high load. 
 But I suspect that there is not much difference between returning a 5xx 
 response and serving a cached pseudo-static version of a resource. It should 
 be much easier to implement the latter (which lots of servers obviously 
 already do) than to change behavior based on current load.

The header allow high load opt out, as you suggested.  It also allows
general opt-out of prefetching by servers.  Additionally, it is the
only way you'd gather statistics about who has prefetch links
targeting you (from Referer when provided with prefetch).  Without
this header, there is no way at all for servers to gather statistics
on user initiated navigations vs prefetches; with it, you can use
cache-control to make this determination.

I see those as benefits, and I think they're nonzero.  On the cost
side, I see a small increase in the size of prefetch requests (and
that cost is born only by this type of request, not by any other kind)
and the hassle you mentioned in network monitoring.

We can probably agree that the cost of the extra request headers is
minimal, so hopefully that's not a very high hurdle to overcome.

The remaining question then is: how much weight should be given to the
difficulties of network monitoring software authors?

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


Re: [webkit-dev] X-Purpose on prefetching requests

2010-09-28 Thread 蓋文彼德斯
Forgive the second follow up, I want to just clarify something.  See below.

On 28 September 2010 11:58, Alexey Proskuryakov a...@webkit.org wrote:

 I've presented some concerns about the effect of this on enterprise network 
 monitors.


I've thought about this some more, and and I think I don't get this
actually.  Could you clarify for me?

What effect does this header have on network monitoring software,
distinct from prefetching itself?  If we lack the request header, then
network monitoring software can't attribute browsing action to users
at all; any request might be a prefetch.  In the presence of this
header, the network monitoring software can determine which requests
began as prefetches, and, depending on the nature of the response, it
may or may not be able to determine if a later user initiated
navigation to that resource occured.

Doesn't this header actually help network monitoring software?

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


Re: [webkit-dev] XHR responseArrayBuffer attribute

2010-09-28 Thread Maciej Stachowiak

On Sep 28, 2010, at 7:15 AM, Chris Marrin wrote:

 
 On Sep 27, 2010, at 6:37 PM, Maciej Stachowiak wrote:
 
 
 On Sep 27, 2010, at 3:19 PM, Michael Nordman wrote:
 
 Webkit's XHR currently does not keep two copies of the data that I can see. 
 I think we should avoid that.
 
 We could keep the raw data around, which hopefully is directly usable as an 
 ArrayBuffer backing store, and only translate it to text format when/if the 
 client requests responseText. 
 
 Yes, the raw data should be usable without translation in an ArrayBuffer. But 
 we'd still need to make a copy of the raw bits when a new ArrayBuffer is 
 created via responseArrayBuffer(), because that object is mutable.

Is there an immutable variant of ArrayBuffer? If not, we really need one. But 
even without that, note that you don't necessarily need to make an immediate 
copy, you can use copy-on-write.

The immutable variant would be helpful since we could avoid implementing 
threadsafe copy-on-write just to allow efficient passing of ArrayBuffers to 
Workers.

Regards,
Maciej

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


Re: [webkit-dev] Ruby Text Enhancements

2010-09-28 Thread David Hyatt
On Sep 27, 2010, at 3:40 PM, Eric Mader wrote:

 
 Are you saying that subclassing computeLogicalWidth() would still mean that 
 I'm computing the margins at the initial calculation time?
 

You'd be computing them whenever the ruby run's layout changed.  The problem 
with that is if you're setting margins based off surrounding content, you're 
not going to get a layout just because your surroundings changed.

 It just doesn't seem like you can deal with all the corner cases without 
 integrating right into line layout.  I don't see how else you can know if 
 you have adequate available space to actually overhang without knowing what 
 you've seen so far on the line and how much space you have left on the line.
 
 This would require special-casing the ruby blocks in line layout code, right? 
 I was trying to avoid this, hoping that I could just extend the existing ruby 
 objects.
 

Right.  It's kind of a minor miracle that Ruby has gotten this far without 
having to do this though. :)

 This method makes several assumptions that I'm not 100% sure are always 
 safe:
 * That a RenderRuby object holds only 1 RenderRubyRun object.
 
 I believe you can have multiple RenderRubyRuns inside a single RenderRuby.
 
 http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-ruby-element
 
 The ruby element allows one or more spans of phrasing content to be marked 
 with ruby annotations.
 
 * That the text for the ruby text and ruby base are always the direct 
 child of the RenderRubyText and RenderRubyBase object.
 
 I doubt that's a valid assumption.  I assume that you can have a content 
 tree of markup underneath a RenderRubyText and a RenderRubyBase, e.g., if 
 you put in some i and some b.  Anyway, I think you could just ask for 
 the width() of the rubyText() and rubyBase() objects themselves rather than 
 drilling down into their subtrees.
 
 I couldn't figure out how to ask the RenderRubyText and RenderRubyRun objects 
 for their width. They don't support the width() method. What method should I 
 call?
 

They should.  They are RenderBlocks, so they should have width() methods.  You 
may have just been getting bad results because you hooked in before the width 
was computed.  That's why computeLogicalWidth subclassing would work better for 
you.  Let the base class set up the margins and width, and then you override.

dave
(hy...@apple.com)

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


Re: [webkit-dev] XHR responseArrayBuffer attribute

2010-09-28 Thread Chris Marrin

On Sep 28, 2010, at 9:45 AM, Maciej Stachowiak wrote:

 
 On Sep 28, 2010, at 7:15 AM, Chris Marrin wrote:
 
 
 On Sep 27, 2010, at 6:37 PM, Maciej Stachowiak wrote:
 
 
 On Sep 27, 2010, at 3:19 PM, Michael Nordman wrote:
 
 Webkit's XHR currently does not keep two copies of the data that I can 
 see. I think we should avoid that.
 
 We could keep the raw data around, which hopefully is directly usable as an 
 ArrayBuffer backing store, and only translate it to text format when/if the 
 client requests responseText. 
 
 Yes, the raw data should be usable without translation in an ArrayBuffer. 
 But we'd still need to make a copy of the raw bits when a new ArrayBuffer is 
 created via responseArrayBuffer(), because that object is mutable.
 
 Is there an immutable variant of ArrayBuffer? If not, we really need one. But 
 even without that, note that you don't necessarily need to make an immediate 
 copy, you can use copy-on-write.
 
 The immutable variant would be helpful since we could avoid implementing 
 threadsafe copy-on-write just to allow efficient passing of ArrayBuffers to 
 Workers.

There's not an immutable variant, but that's a good idea. I will propose it

-
~Chris
cmar...@apple.com




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


Re: [webkit-dev] Ruby Text Enhancements

2010-09-28 Thread Yasuo Kida

On 2010/09/28, at 10:11, David Hyatt wrote:
 On Sep 27, 2010, at 3:40 PM, Eric Mader wrote:
 Are you saying that subclassing computeLogicalWidth() would still mean that 
 I'm computing the margins at the initial calculation time?
 
 You'd be computing them whenever the ruby run's layout changed.  The problem 
 with that is if you're setting margins based off surrounding content, you're 
 not going to get a layout just because your surroundings changed.

Probably a novice question but are there mechanisms or ways to trigger 
re-computing of the ruby's layout when the surrounding text has changed?

- kida

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


Re: [webkit-dev] XHR responseArrayBuffer attribute

2010-09-28 Thread Kenneth Russell
On Tue, Sep 28, 2010 at 9:45 AM, Maciej Stachowiak m...@apple.com wrote:

 On Sep 28, 2010, at 7:15 AM, Chris Marrin wrote:


 On Sep 27, 2010, at 6:37 PM, Maciej Stachowiak wrote:


 On Sep 27, 2010, at 3:19 PM, Michael Nordman wrote:

 Webkit's XHR currently does not keep two copies of the data that I can 
 see. I think we should avoid that.

 We could keep the raw data around, which hopefully is directly usable as an 
 ArrayBuffer backing store, and only translate it to text format when/if the 
 client requests responseText.

 Yes, the raw data should be usable without translation in an ArrayBuffer. 
 But we'd still need to make a copy of the raw bits when a new ArrayBuffer is 
 created via responseArrayBuffer(), because that object is mutable.

 Is there an immutable variant of ArrayBuffer? If not, we really need one. But 
 even without that, note that you don't necessarily need to make an immediate 
 copy, you can use copy-on-write.

 The immutable variant would be helpful since we could avoid implementing 
 threadsafe copy-on-write just to allow efficient passing of ArrayBuffers to 
 Workers.

Chris has raised this issue on the public_webgl list, and we've begun
discussion there, but I would like to point out that having an
immutable ArrayBuffer and views on it does not help with the situation
of passing data to or from a web worker. The side that constructs the
data will necessarily have a mutable view, so it will be able to cause
changes that can be seen on the other side even if the view on the
other side is immutable.

We have a design that will allow efficient zero-copy producer/consumer
queues to be implemented using TypedArrays while maintaining
ECMAScript's shared-nothing semantics. I'll be happy to sketch it out,
but it's probably most appropriate for a mailing list like
public_webgl.

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


Re: [webkit-dev] XHR responseArrayBuffer attribute

2010-09-28 Thread Maciej Stachowiak

On Sep 28, 2010, at 11:05 AM, Kenneth Russell wrote:

 On Tue, Sep 28, 2010 at 9:45 AM, Maciej Stachowiak m...@apple.com wrote:
 
 On Sep 28, 2010, at 7:15 AM, Chris Marrin wrote:
 
 
 On Sep 27, 2010, at 6:37 PM, Maciej Stachowiak wrote:
 
 
 On Sep 27, 2010, at 3:19 PM, Michael Nordman wrote:
 
 Webkit's XHR currently does not keep two copies of the data that I can 
 see. I think we should avoid that.
 
 We could keep the raw data around, which hopefully is directly usable as 
 an ArrayBuffer backing store, and only translate it to text format when/if 
 the client requests responseText.
 
 Yes, the raw data should be usable without translation in an ArrayBuffer. 
 But we'd still need to make a copy of the raw bits when a new ArrayBuffer 
 is created via responseArrayBuffer(), because that object is mutable.
 
 Is there an immutable variant of ArrayBuffer? If not, we really need one. 
 But even without that, note that you don't necessarily need to make an 
 immediate copy, you can use copy-on-write.
 
 The immutable variant would be helpful since we could avoid implementing 
 threadsafe copy-on-write just to allow efficient passing of ArrayBuffers to 
 Workers.
 
 Chris has raised this issue on the public_webgl list, and we've begun
 discussion there, but I would like to point out that having an
 immutable ArrayBuffer and views on it does not help with the situation
 of passing data to or from a web worker. The side that constructs the
 data will necessarily have a mutable view, so it will be able to cause
 changes that can be seen on the other side even if the view on the
 other side is immutable.

Not if the side that got the data got it in immutable form in the first place. 
For example, if you get an immutable ArrayBuffer from XHR in a Worker, then you 
can pass it to another Worker or to the main thread without the need for any 
copying or copy-on-write.

 
 We have a design that will allow efficient zero-copy producer/consumer
 queues to be implemented using TypedArrays while maintaining
 ECMAScript's shared-nothing semantics. I'll be happy to sketch it out,
 but it's probably most appropriate for a mailing list like
 public_webgl.

I'm curious to hear it and I don't follow public_webgl.

I'd specifically like to handle the following case:
- You obtain a chunk of binary data from the network or filesystem and want to 
pass it to another thread without copying.

Regards,
Maciej

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


Re: [webkit-dev] X-Purpose on prefetching requests

2010-09-28 Thread Alexey Proskuryakov

28.09.2010, в 9:43, Gavin Peters (蓋文彼德斯) написал(а):

 I've presented some concerns about the effect of this on enterprise network 
 monitors.
 
 I've thought about this some more, and and I think I don't get this
 actually.  Could you clarify for me?


I think that it changes false positives to false negatives. Without the header, 
it will complain about prefetch requests made for Google search results. But 
once the monitoring software learns to ignore prefetch requests, then it will 
be easy to circumvent it by adding X-Purpose to every request (e.g. with a 
browser extension). Doomed both ways.

It seems that the only real way to make prefetch safe may be to limit it to 
same origin URLs. Yes, one can always do their own prefetching via a hidden 
frame, but the purpose of explicit prefetch was to make it semantically clean, 
and that doesn't seem to work without imposing a same origin restriction.

- WBR, Alexey Proskuryakov

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


Re: [webkit-dev] Ruby Text Enhancements

2010-09-28 Thread Eric Mader

On Sep 28, 2010, at 7:11 AM, David Hyatt wrote:

 The ruby element allows one or more spans of phrasing content to be marked 
 with ruby annotations.
 
 * That the text for the ruby text and ruby base are always the direct 
 child of the RenderRubyText and RenderRubyBase object.
 
 I doubt that's a valid assumption.  I assume that you can have a content 
 tree of markup underneath a RenderRubyText and a RenderRubyBase, e.g., if 
 you put in some i and some b.  Anyway, I think you could just ask for 
 the width() of the rubyText() and rubyBase() objects themselves rather than 
 drilling down into their subtrees.
 
 I couldn't figure out how to ask the RenderRubyText and RenderRubyRun 
 objects for their width. They don't support the width() method. What method 
 should I call?
 
 
 They should.  They are RenderBlocks, so they should have width() methods.  
 You may have just been getting bad results because you hooked in before the 
 width was computed.  That's why computeLogicalWidth subclassing would work 
 better for you.  Let the base class set up the margins and width, and then 
 you override.

Doh! I was trying to call width() on RenderText objects. When I called it 
directly on firstChild() and lastChild() of the RenderRubyRun, it works, but 
returns the frame width, which isn't useful for my purposes. Instead I called 
maxPrefWidth() which has the values I'm after. (only, I guess, if the ruby text 
and ruby base is a single line…)

 dave
 (hy...@apple.com)

Regards,
Eric

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


Re: [webkit-dev] X-Purpose on prefetching requests

2010-09-28 Thread Adam Barth
2010/9/28 Alexey Proskuryakov a...@webkit.org:
 28.09.2010, в 9:43, Gavin Peters (�w文彼德斯) написал(а):
 I've presented some concerns about the effect of this on enterprise network 
 monitors.

 I've thought about this some more, and and I think I don't get this
 actually.  Could you clarify for me?

 I think that it changes false positives to false negatives. Without the 
 header, it will complain about prefetch requests made for Google search 
 results. But once the monitoring software learns to ignore prefetch requests, 
 then it will be easy to circumvent it by adding X-Purpose to every request 
 (e.g. with a browser extension). Doomed both ways.

 It seems that the only real way to make prefetch safe may be to limit it to 
 same origin URLs. Yes, one can always do their own prefetching via a hidden 
 frame, but the purpose of explicit prefetch was to make it semantically 
 clean, and that doesn't seem to work without imposing a same origin 
 restriction.

Hum...  Restricting prefetching to a single origin would seem to
defeat much of the point of the feature in the first place.  Folks who
want to do prefetch will just end up using an image tag instead.

Alexey, it seems like your objection to the X-Purpose header is based
on the belief that servers and network monitors won't use the
information correctly.  Is there evidence that these folks make these
mistakes with the similar X-Moz header used by Firefox?  What about
the X-Purpose header as used by Safari already?

To counterbalance these concerns, we'll gotten feedback from server
operators that they're sad that WebKit lacks the X-Moz header on
prefetch requests, which they find useful.  From talking with these
folks, it seems like they'll live happier lives if we include this
information in prefetch requests.  Given that the cost of including
the information is low and there's already ample implementation
experience from Firefox and Safari, including the information seems
like the right call, on balance.

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


Re: [webkit-dev] X-Purpose on prefetching requests

2010-09-28 Thread Adam Barth
I guess I don't understand your perspective.  Are you arguing that
prefetch is a misfeature and folks should use image tags instead?
That doesn't really make sense to me.  For example, using an explicit
prefect API means the prefetch gets properly prioritized and doesn't
delay the load event.  Below you characterize prefetch as a hack, but
it seems like a useful feature that's used by a bunch of sites.

As for X-Purpose, sometimes you seem to be saying that it can't be
used correctly, whereas other times you seem to be saying that it can
be used correctly, just that sites will screw it up.  At the beginning
of the discussion, you seemed worried about the size increase to
requests.  Reading your messages, it feels like you don't like
X-Purpose, but you're not quite sure why.  As the discussion
progresses, your reasons for disliking it seem to shift.

Server operators seem to be sad that we're don't have the same feature
as Firefox.  I don't understand why we shouldn't make them happier.

Adam


2010/9/28 Alexey Proskuryakov a...@webkit.org:
 28.09.2010, в 12:53, Adam Barth написал(а):
 Hum...  Restricting prefetching to a single origin would seem to
 defeat much of the point of the feature in the first place.  Folks who
 want to do prefetch will just end up using an image tag instead.

 Yes, that sounds likely. But why was link prefetch added if it's unnecessary? 
 I have two guesses:
 - syntactic sugar;
 - trying to do it semantically right, providing a way to solve the set of 
 problems with prefetch we've just discussed.

 I think that the discussion that we're having now shows that the second goal 
 cannot be achieved, at least not without some new ideas. Telling servers what 
 part of WebCore initiated the request only shifts the blame on someone else 
 (we've provided complete information to the server, and washed our hands).

 Alexey, it seems like your objection to the X-Purpose header is based
 on the belief that servers and network monitors won't use the
 information correctly.  Is there evidence that these folks make these
 mistakes with the similar X-Moz header used by Firefox?

 It actually appears that it cannot be used correctly, not just that it won't 
 be.

 What about the X-Purpose header as used by Safari already?

 As far as Safari implementation experience goes, I'd like to re-iterate that 
 preview is quite different in this respect, I don't think it's sufficiently 
 related to be given as an example. There is no expectation that fetching a 
 page for preview will make navigating to it faster in the future - and 
 fulfilling that expectation is one of the central problem with prefetch. 
 There is no question of whether fetching for preview means access for network 
 security monitors either - you only prefetch for sites that were previously 
 visited, roughly speaking.

 To counterbalance these concerns, we'll gotten feedback from server
 operators that they're sad that WebKit lacks the X-Moz header on
 prefetch requests, which they find useful.

 It's undoubtedly a problem for server operators when another site prefetches 
 their resources indiscriminately (exactly as it would be if someone used 
 display:none or img tag prefetch indiscriminately). Unfortunately, link 
 prefetch looks as if it were less of a hack, encouraging people to use it.

 - WBR, Alexey Proskuryakov


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


[webkit-dev] Should we recommend explicit constructors as part of WebKit style?

2010-09-28 Thread David Levin
This came up before:
https://lists.webkit.org/pipermail/webkit-dev/2010-May/012873.html but I'd
like to understand it a bit better.

It feels there were two points of view:

   1. Use explicit only when necessary to prevent an undesirable implicit
   conversion like int to vector.
   2. Use explicit except when it is desirable to allow an implicit
   conversion that makes the code simpler. For example, the String -
   AtomicString makes the bindings generator code simpler since it doesn't need
   to know which the underlying method takes.

Are there any reasons beyond personal preference to select either of these?

Starting list:

Pro's for #1
  It is a pain to remember to put explicit every time you have a constructor
with one argument.

Pro's for #2
   It would prevent accidental mistakes that happen with implicit
constructors.

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


Re: [webkit-dev] Should we recommend explicit constructors as part of WebKit style?

2010-09-28 Thread Darin Fisher
On Tue, Sep 28, 2010 at 4:26 PM, David Levin le...@google.com wrote:

 This came up before:
 https://lists.webkit.org/pipermail/webkit-dev/2010-May/012873.html but I'd
 like to understand it a bit better.

 It feels there were two points of view:

1. Use explicit only when necessary to prevent an undesirable implicit
conversion like int to vector.
2. Use explicit except when it is desirable to allow an implicit
conversion that makes the code simpler. For example, the String -
AtomicString makes the bindings generator code simpler since it doesn't 
 need
to know which the underlying method takes.

 Are there any reasons beyond personal preference to select either of these?

 Starting list:

 Pro's for #1
   It is a pain to remember to put explicit every time you have a
 constructor with one argument.

 Pro's for #2
It would prevent accidental mistakes that happen with implicit
 constructors.


We're there some recent mishaps with implicit constructors that motivate
this thread?
-Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Should we recommend explicit constructors as part of WebKit style?

2010-09-28 Thread Maciej Stachowiak

On Sep 28, 2010, at 4:26 PM, David Levin wrote:

 This came up before: 
 https://lists.webkit.org/pipermail/webkit-dev/2010-May/012873.html but I'd 
 like to understand it a bit better.
 
 It feels there were two points of view:
 Use explicit only when necessary to prevent an undesirable implicit 
 conversion like int to vector.
 Use explicit except when it is desirable to allow an implicit conversion that 
 makes the code simpler. For example, the String - AtomicString makes the 
 bindings generator code simpler since it doesn't need to know which the 
 underlying method takes.
 Are there any reasons beyond personal preference to select either of these?
 
 Starting list:
 
 Pro's for #1
   It is a pain to remember to put explicit every time you have a constructor 
 with one argument.
 
 Pro's for #2
It would prevent accidental mistakes that happen with implicit 
 constructors.

I think the rule should be something like:

  3. Do not explicit when the single-argument constructor can be thought of as 
a type conversion - the class will be in some sense an alternate form of its 
sole parameter. Do use explicit when the single-argument constructor is *not* 
reasonably thought of as a type conversion - the single argument just happens 
to be the sole initialization parameter. Or to put it another way - can you 
imagine having a type conversion operator overload that does the same thing as 
this constroctor?

Applying this rule to your two examples, Vector(int) should be explicit, 
because it doesn't convert the int to a vector, it uses the int as a size 
instead of the default one. But String(AtomicString) or AtomicString(String) 
need not be explicit, since they convert from one string type to another, 
carrying largely the same data.

I realize this rule requires some judgment, so it's worse than a purely 
mechanical rule, but I think it accurately captures the proper use of explicit.

Regards,
Maciej

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


Re: [webkit-dev] X-Purpose on prefetching requests

2010-09-28 Thread Maciej Stachowiak

On Sep 28, 2010, at 4:16 PM, Adam Barth wrote:

 I guess I don't understand your perspective.  Are you arguing that
 prefetch is a misfeature and folks should use image tags instead?
 That doesn't really make sense to me.  For example, using an explicit
 prefect API means the prefetch gets properly prioritized and doesn't
 delay the load event.  Below you characterize prefetch as a hack, but
 it seems like a useful feature that's used by a bunch of sites.
 
 As for X-Purpose, sometimes you seem to be saying that it can't be
 used correctly, whereas other times you seem to be saying that it can
 be used correctly, just that sites will screw it up.  At the beginning
 of the discussion, you seemed worried about the size increase to
 requests.  Reading your messages, it feels like you don't like
 X-Purpose, but you're not quite sure why.  As the discussion
 progresses, your reasons for disliking it seem to shift.
 
 Server operators seem to be sad that we're don't have the same feature
 as Firefox.  I don't understand why we shouldn't make them happier.

I'll try to find out the reasons we added X-Purpose: preview to Safari's 
snapshot fetcher. If similar use cases apply to prefetch, then that seems like 
a strong argument to add X-Purpose: prefetch.

Regards,
Maciej

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


Re: [webkit-dev] Should we recommend explicit constructors as part of WebKit style?

2010-09-28 Thread Darin Adler
On Sep 28, 2010, at 4:31 PM, Maciej Stachowiak wrote:

 I think the rule should be something like:
 
   3. Do not explicit when the single-argument constructor can be thought of 
 as a type conversion - the class will be in some sense an alternate form of 
 its sole parameter. Do use explicit when the single-argument constructor is 
 *not* reasonably thought of as a type conversion - the single argument just 
 happens to be the sole initialization parameter. Or to put it another way - 
 can you imagine having a type conversion operator overload that does the same 
 thing as this constroctor?
 
 Applying this rule to your two examples, Vector(int) should be explicit, 
 because it doesn't convert the int to a vector, it uses the int as a size 
 instead of the default one. But String(AtomicString) or AtomicString(String) 
 need not be explicit, since they convert from one string type to another, 
 carrying largely the same data.
 
 I realize this rule requires some judgment, so it's worse than a purely 
 mechanical rule, but I think it accurately captures the proper use of 
 explicit.

This seems like a good rule. I agree completely that it’s the right principle.

When the conversion between types is costly enough, there may be some cases 
where we don’t want to offer an implicit constructor. Specifically, the 
implicit conversion from String to AtomicString may be a mistake; we might be 
better off if we had to utter some explicit function name every time we wanted 
a string looked up in the atomic string table.

I don’t think of this, though, as a rule for when to use “explicit”. It’s a 
rule for when to use a constructor that can be used implicitly for type 
conversion. If a constructor can’t be used that way, an explicit constructor 
might be OK, or you might not want the other constructor to exist at all. For 
example, if we want to be more explicit about the cost of looking up an 
AtomicString, the syntax for making an AtomicString from a String should 
probably be a named function, not AtomicString(string).

-- Darin

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


Re: [webkit-dev] Should we recommend explicit constructors as part of WebKit style?

2010-09-28 Thread David Levin
On Tue, Sep 28, 2010 at 4:30 PM, Oliver Hunt oli...@apple.com wrote:

 Pro's for #1
   It is a pain to remember to put explicit every time you have a
 constructor with one argument.

 Could check-webkit-style be beaten into forcing this for us?


Yep, check-webkit-style could check this automatically, but it wouldn't be
subtle, so it would flag cases where we want an implicit constructor. It
would just have to point to the guideline. (The check is currently turned
off because this isn't WebKit style.)


On Tue, Sep 28, 2010 at 4:29 PM, Darin Fisher da...@chromium.org wrote:

 We're there some recent mishaps with implicit constructors that motivate
 this thread?


I've noticed Adam Barth putting comments in reviews about it (and
check-webkit-style could do it automatically for him). I tend to think it is
a good thing (and have been bitten in the past by not doing it), but I don't
usually notice it in reviews.

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


Re: [webkit-dev] X-Purpose on prefetching requests

2010-09-28 Thread Alexey Proskuryakov

28.09.2010, в 16:16, Adam Barth написал(а):

 I guess I don't understand your perspective.  Are you arguing that
 prefetch is a misfeature and folks should use image tags instead?
 That doesn't really make sense to me.  For example, using an explicit
 prefect API means the prefetch gets properly prioritized and doesn't
 delay the load event.

This wasn't a preconceived idea of mine when starting this discussion. However, 
I'm actually beginning to think that cross-origin prefetch may be a misfeature 
indeed. It's one thing to optimize one's own site loading, and another to use 
someone else's bandwidth. The effects this has on statistics and network 
monitoring are secondary reasons to doubt that this is a good idea.

The benefit of cross origin prefetching seems to be limited, too. In most 
cases, you can only prefetch the main resource, which likely requires 
revalidation anyway.

  Below you characterize prefetch as a hack, but
 it seems like a useful feature that's used by a bunch of sites.
 
 As for X-Purpose, sometimes you seem to be saying that it can't be
 used correctly, whereas other times you seem to be saying that it can
 be used correctly, just that sites will screw it up.  At the beginning
 of the discussion, you seemed worried about the size increase to
 requests.  Reading your messages, it feels like you don't like
 X-Purpose, but you're not quite sure why.  As the discussion
 progresses, your reasons for disliking it seem to shift.

Yes, this is a correct impression. I'm not sure why you look at this as 
something negative. I didn't know about the consequences of link prefetch much 
in the beginning, and reacted to this patch simply because it smelled wrong 
(disclose more information without saying a word about why that's beneficial, 
and why it's not dangerous). The new arguments that are being provided are 
worth answering, and it's only fair that each gets its own answer.

Others have also noticed that there were major questions that weren't answered 
in https://bugs.webkit.org/show_bug.cgi?id=46529, or in any discussion linked 
from it.

 Server operators seem to be sad that we're don't have the same feature
 as Firefox.  I don't understand why we shouldn't make them happier.


This is a good argument for spending time on designing a feature, not 
necessarily so for shipping it.

- WBR, Alexey Proskuryakov

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


Re: [webkit-dev] Ruby Text Enhancements

2010-09-28 Thread Yasuo Kida
Thanks. Looks like hooking findNextLineBreak is something we should try.

- kida

On 2010/09/28, at 12:56, David Hyatt wrote:

 On Sep 28, 2010, at 12:20 PM, Yasuo Kida wrote:
 
 
 On 2010/09/28, at 10:11, David Hyatt wrote:
 On Sep 27, 2010, at 3:40 PM, Eric Mader wrote:
 Are you saying that subclassing computeLogicalWidth() would still mean 
 that I'm computing the margins at the initial calculation time?
 
 You'd be computing them whenever the ruby run's layout changed.  The 
 problem with that is if you're setting margins based off surrounding 
 content, you're not going to get a layout just because your surroundings 
 changed.
 
 Probably a novice question but are there mechanisms or ways to trigger 
 re-computing of the ruby's layout when the surrounding text has changed?
 
 In this case, you really don't need to re-layout the RenderRubyRun itself.  
 You just need to possibly change its margins.  I think hooking into 
 findNextLineBreak is the easiest way to do this, since you can see your 
 surroundings and figure out what it is you'd be overlapping and how much room 
 you have on the line.
 
 dave
 (hy...@apple.com)
 

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


Re: [webkit-dev] X-Purpose on prefetching requests

2010-09-28 Thread Alexey Proskuryakov

28.09.2010, в 17:07, Gavin Peters (蓋文彼德斯) написал(а):

 If you're questioning if prefetch can make page loads faster, I can
 say that on the web today it does.

Thank you for the information.

Does the performance increase come at the cost of correctness? I.e., are these 
sites requiring revalidation on each load?

 The samples of prefetching on the web today are mostly cross site.

Can you provide any examples?

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


Re: [webkit-dev] X-Purpose on prefetching requests

2010-09-28 Thread 蓋文彼德斯
On 28 September 2010 20:25, Alexey Proskuryakov a...@webkit.org wrote:

 28.09.2010, в 17:07, Gavin Peters (蓋文彼德斯) написал(а):

 If you're questioning if prefetch can make page loads faster, I can
 say that on the web today it does.

 Thank you for the information.

 Does the performance increase come at the cost of correctness? I.e., are 
 these sites requiring revalidation on each load?

That's a great question, and I don't have data on it in aggregate.
The only examples I know of for pages varying behaviour based on the
X-Moz header are sites that deny prefetches.

I hope that revalidation will end up being somewhat rare: adding a RTT
to the root document of a page of course slows down first paint,
onload, etc.. by pretty much exactly one RTT.  If correctness requires
it, so be it, but if a resource would have been cacheable on a
user-initiated load, I hope site operators would allow it to be
cacheable for prefetchers over the same period.  Of course, this is
the default behaviour now, and it's the one that webkit enforces.


 The samples of prefetching on the web today are mostly cross site.

 Can you provide any examples?

Yes.  Google Web Search provides a prefetch link to the first search
result in many cases.  These links are (almost?) always cross site.

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


[webkit-dev] JSC binding code question

2010-09-28 Thread Kinuko Yasuda
Hi Webkit folks,

I'm writing a JSC binding code (custom binding code for now) for a
method that can take JSON-format parameters, and I want to know what
would be the right/recommended way.
I mean, I want to write a binding code that can executes javascript code like:

   directoryEntry.getFile(lockfile.txt, {create: true, exclusive: true});

Where the getFile() method is defined as:

   interface DirectoryEntry : Entry {
 void getFile(in DOMString path, in Flags flags, /* ... */);
   };
   interface Flags {
 attribute boolean create;
 attribute boolean exclusive;
   };

(They are from the File API: Directories and System's draft [1])

And what I have written for this is like following:

if (!exec-argument(1).isNull()  !exec-argument(1).isUndefined() 
exec-argument(1).isObject() 
!exec-argument(1).inherits(JSFlags::s_info)) {
JSObject* object = exec-argument(1).getObject();
flags = Flags::create();
JSValue jsCreate = object-get(exec, Identifier(exec, create));
flags-setCreate(jsCreate.toBoolean(exec));
JSValue jsExclusive = object-get(exec, Identifier(exec, exclusive));
flags-setExclusive(jsExclusive.toBoolean(exec));
}

Basically the code calls JSObject::get() to get values for the given
property names.
This looked straightforward, but I was told that the get(exec)
re-enters Javascript and could do any arbitrary thing.
This means that during the get() even the parameter object or the
calling object (imp) may get deallocated.

So here I have two questions:

1) How can I write a safe binding code that reads JSON-format
parameters?  Is there some recommended way or any good idea?

2) I saw several other code doing the same/similar thing as I do
(calling JSObject::get()) to get arbitrary parameter values.
Are they safe?  Is there a guarantee that the code executed during
get() doesn't deallocate some objects?

Any help/suggestions/comments would be highly appreciated.
Thanks!
Kinuko


[1] http://dev.w3.org/2009/dap/file-system/file-dir-sys.html
[2] 
http://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSDirectoryEntryCustom.cpp
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev