Re: [webkit-dev] XHR responseArrayBuffer attribute
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
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
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
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
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
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
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
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
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
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
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
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
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
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/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
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?
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?
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?
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
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?
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?
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
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
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
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
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
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