[webkit-dev] SVN server seems hung?
Anyone know how to poke it? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SVN server seems hung?
I took care of it. -Bill On Jan 28, 2011, at 12:41 AM, Eric Seidel wrote: Anyone know how to poke it? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] about QtWebKit documentation
I'm not clear from your question what you're trying to do. If you're just trying to write an app using the Qt port of WebKit, you should ask on webkit-h...@lists.webkit.orgmailto:webkit-h...@lists.webkit.org. This list is only for developing WebKit itself. The interface layer between Qt and WebKit is in webkit/WebKit/qt/Api. Docs are at http://doc.qt.nokia.com/4.7/qtwebkit.html From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Kanazawa Yoshiko Sent: Thursday, January 27, 2011 9:53 PM To: webkit-dev@lists.webkit.org Subject: [webkit-dev] about QtWebKit documentation Hi,everyone. I am new here. I have a question about Qtwebkit documentation. I found very similar question http://lists.trolltech.com/qt-interest/2008-09/msg00805.html (more than 2 years ago) but it seems he didn't get clear answer. So I post here again,sorry. His question is almost the same with me.I am writing a technical document too. 1) where is the exact interface layer between QT and WEBKIT? Source is maybe here webkit\WebCore\platform If there are some documentation to help my understandings. 2) What are the APIs or Data structures, when we send data to WebCore for parsing? Already I have read about demo browser source but don't know where to start to search about that question. Thank you so much for any help Yoshiko - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] coding style and comments
On Thu, Jan 27, 2011 at 4:27 PM, Simon Fraser simon.fra...@apple.comwrote: I think we have a distinct lack of comments that help novices to understand the code. I feel that we almost have a privileged few mentality in some code; if you can't figure it out by reading the code, then you shouldn't be messing with it. Indeed. This sets a high barrier to entry when trying to learn about any nontrivial subsystem. Even when functions are kept brief and well-named, local simplicity does not eliminate global complexity; in fact it can mask it, making the system appear saner than it really is. In this sense, I disagree that self-documenting code is possible on a large scale (even though I am certainly a fan of making the small-scale units concise, clear, etc.). Back when we were writing the initial Chromium port, Brett Wilson and I had to rewrite the Image subsystem three separate times, each time because we realized we'd gotten the ownership semantics wrong and thought we now understood things better. In this case, a simple function that merely allocates an object is deceptively self-documenting, because it's clear what it does in a local sense, but not in the larger picture of how it fits into the rest of the codebase. No one is suggesting that silly comments like for (int i = 0; i 10; ++i) // Count to 10. are a good thing, but I have never had any reviewer objections to adding more detailed comments about subtle bits. At the very least I agree with Simon's suggestion of class-level comments, especially w.r.t. ownership. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] coding style and comments
28.01.2011, в 9:36, Peter Kasting написал(а): At the very least I agree with Simon's suggestion of class-level comments, especially w.r.t. ownership. I remember this comment http://trac.webkit.org/browser/trunk/WebCore/platform/PlatformString.h?rev=16622#L44 causing trouble. Here is some history if you're interested: https://bugs.webkit.org/show_bug.cgi?id=11555#c5 https://bugs.webkit.org/show_bug.cgi?id=16550 http://trac.webkit.org/changeset/28977/trunk/WebCore/platform/text/PlatformString.h This comment has evolved into comments for crossThreadString() and threadsafeCopy() - and while these are useful, they are not up to date, mentioning a non-existent copy() function. Do you have any specific mechanism in mind for keeping global comments accurate? Personally, I expect that adding such comments will make the barrier for entry higher in practice, as one would have to deal with lies. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] coding style and comments
On Fri, Jan 28, 2011 at 10:14 AM, Alexey Proskuryakov a...@webkit.org wrote: Do you have any specific mechanism in mind for keeping global comments accurate? No more than I have for keeping API usage or function implementations correct; that is, if we have comments, they must be as important to reviewers and patch authors as the code is. Personally, I expect that adding such comments will make the barrier for entry higher in practice, as one would have to deal with lies. At least for me, WebKit subsystems have always been much harder to learn than equivalent-complexity Chromium subsystems (in Chromium we strongly encourage comments, and our style guide mandates at least class-level ones). I have heard this sentiment echoed by others but I can't say whether it's a majority viewpoint. No system is perfect, but I have not found out-of-date comments in Chromium to be a big problem, presumably because the culture prods people to keep them up to date. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] coding style and comments
On Jan 27, 2011, at 4:38 PM, Dirk Pranke wrote:
I agree with all of the sentiments below, except for possibly one or two
cases.
Namely, sometimes you write code where the what is not obvious. In
that situation, it may not be possible to change the code to make it
more obvious, because you are bound by contract. For example, suppose
you are implementing an interface with a method called sort(). The
fact that you choose a quicksort or a mergesort is a useful one-line
comment, and in my opinion is probably better than just wrapping a
method called quicksort() and hoping it gets inlined away.
I ran into this exact situation. I wanted to add a sort function that doesn't
copy, only swaps. It happens that heapsort is such an algorithm. I named the
public interface nonCopyingSort, made it call a function named heapSort, and
wrote a comment explaining why heapSort is an appropriate implementation for
nonCopyingSort:
http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/NonCopyingSort.h
templatetypename RandomAccessIterator, typename Predicate
inline void nonCopyingSort(RandomAccessIterator start, RandomAccessIterator
end, Predicate compareLess)
{
// heapsort happens to use only swaps, not copies, but the essential thing
about
// this function is the fact that it does not copy, not the specific
algorithm
heapSort(start, end, compareLess);
}
Inlining works. IMO it's always better to use a well-named function to document
what your code does than a comment. In this case I did it even though I also
had a comment explaining why the function uses heapsort.
A slight variant of this is that you may be learning or
reverse-engineering code where the what is not clear (perhaps
because it was poorly rewritten). In the longer-term, ideally you'd
clean up the code, but in the short term it might be useful to capture
the what in comments until you can safely refactor things and delete
the comments.
I would prefer for people to refactor instead of adding explanatory comments.
In general, I agree with what Eric and Darin said about this topic.
Regards,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Same Origin Restriction on WOFF fonts across WebKit
The WOFF font specification requires that browsers apply Same Origin Restrictions (SOR) to WOFF fonts. So far, Firefox and IE9 follow this requirement, while we and Opera don't. As far as I know, our lack of SOR is basically an accident; we implemented support for WOFF before this requirement was added, and just haven't gotten around to adding it in yet. Chrome people seem amenable to applying SOR to WOFF fonts in Chrome. Is it okay to add this across all our webkit ports? ~TJ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Same Origin Restriction on WOFF fonts across WebKit
On Jan 28, 2011, at 3:06 PM, Tab Atkins Jr. wrote: The WOFF font specification requires that browsers apply Same Origin Restrictions (SOR) to WOFF fonts. So far, Firefox and IE9 follow this requirement, while we and Opera don't. As far as I know, our lack of SOR is basically an accident; we implemented support for WOFF before this requirement was added, and just haven't gotten around to adding it in yet. Chrome people seem amenable to applying SOR to WOFF fonts in Chrome. Is it okay to add this across all our webkit ports? It's not an accident. It has been our intent to willfully ignore this requirement. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Same Origin Restriction on WOFF fonts across WebKit
On Fri, Jan 28, 2011 at 3:11 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 28, 2011, at 3:06 PM, Tab Atkins Jr. wrote: The WOFF font specification requires that browsers apply Same Origin Restrictions (SOR) to WOFF fonts. So far, Firefox and IE9 follow this requirement, while we and Opera don't. As far as I know, our lack of SOR is basically an accident; we implemented support for WOFF before this requirement was added, and just haven't gotten around to adding it in yet. Chrome people seem amenable to applying SOR to WOFF fonts in Chrome. Is it okay to add this across all our webkit ports? It's not an accident. It has been our intent to willfully ignore this requirement. What's the long-term plan here? Are we hoping the other folks will come around to this point of view eventually? From a game-theory point-of-view, it seems likely that the most permissive behavior is likely to become wide-spread over time. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Same Origin Restriction on WOFF fonts across WebKit
On Fri, Jan 28, 2011 at 3:11 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 28, 2011, at 3:06 PM, Tab Atkins Jr. wrote: The WOFF font specification requires that browsers apply Same Origin Restrictions (SOR) to WOFF fonts. So far, Firefox and IE9 follow this requirement, while we and Opera don't. As far as I know, our lack of SOR is basically an accident; we implemented support for WOFF before this requirement was added, and just haven't gotten around to adding it in yet. Chrome people seem amenable to applying SOR to WOFF fonts in Chrome. Is it okay to add this across all our webkit ports? It's not an accident. It has been our intent to willfully ignore this requirement. Can you please clarify whom you mean by our and the reason for ignoring it? Do we expect this to change in the future and/or are efforts being made to see it happen? J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Same Origin Restriction on WOFF fonts across WebKit
On Jan 28, 2011, at 3:44 PM, Adam Barth wrote: On Fri, Jan 28, 2011 at 3:11 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 28, 2011, at 3:06 PM, Tab Atkins Jr. wrote: The WOFF font specification requires that browsers apply Same Origin Restrictions (SOR) to WOFF fonts. So far, Firefox and IE9 follow this requirement, while we and Opera don't. As far as I know, our lack of SOR is basically an accident; we implemented support for WOFF before this requirement was added, and just haven't gotten around to adding it in yet. Chrome people seem amenable to applying SOR to WOFF fonts in Chrome. Is it okay to add this across all our webkit ports? It's not an accident. It has been our intent to willfully ignore this requirement. What's the long-term plan here? Are we hoping the other folks will come around to this point of view eventually? From a game-theory point-of-view, it seems likely that the most permissive behavior is likely to become wide-spread over time. A number of us at Apple who have followed downloadable fonts are not keen on adding pseudo-DRM code to WebKit. That's not the way the Web has worked historically, and there doesn't seem to be a good reason to special-case fonts. It's true that other people have come to the opposite conclusion, but there doesn't seem to be much reason to take their point of view. We also think it's bad to have this requirement in the spec. But we are willing to ignore the spec if it's not changed, as with other specs that we think are a bad idea. I don't think we are too concerned with whether other implementors come around to this idea, since it's unlikely to hurt our compatibility. We think of it as having an extra feature. Bottom line: if there's a strong desire to do this for Chrome, please at least make it switchable so we don't have to enable it for Safari. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Same Origin Restriction on WOFF fonts across WebKit
On Fri, Jan 28, 2011 at 4:07 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 28, 2011, at 3:44 PM, Adam Barth wrote: On Fri, Jan 28, 2011 at 3:11 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 28, 2011, at 3:06 PM, Tab Atkins Jr. wrote: The WOFF font specification requires that browsers apply Same Origin Restrictions (SOR) to WOFF fonts. So far, Firefox and IE9 follow this requirement, while we and Opera don't. As far as I know, our lack of SOR is basically an accident; we implemented support for WOFF before this requirement was added, and just haven't gotten around to adding it in yet. Chrome people seem amenable to applying SOR to WOFF fonts in Chrome. Is it okay to add this across all our webkit ports? It's not an accident. It has been our intent to willfully ignore this requirement. What's the long-term plan here? Are we hoping the other folks will come around to this point of view eventually? From a game-theory point-of-view, it seems likely that the most permissive behavior is likely to become wide-spread over time. A number of us at Apple who have followed downloadable fonts are not keen on adding pseudo-DRM code to WebKit. That's not the way the Web has worked historically, and there doesn't seem to be a good reason to special-case fonts. It's true that other people have come to the opposite conclusion, but there doesn't seem to be much reason to take their point of view. We also think it's bad to have this requirement in the spec. But we are willing to ignore the spec if it's not changed, as with other specs that we think are a bad idea. I don't think we are too concerned with whether other implementors come around to this idea, since it's unlikely to hurt our compatibility. We think of it as having an extra feature. Bottom line: if there's a strong desire to do this for Chrome, please at least make it switchable so we don't have to enable it for Safari. When the webfont discussion started, two years ago on the CSSWG mailing list, Safari appeared to be in favor of SOR http://lists.w3.org/Archives/Public/www-style/2008Oct/0185.html. I'm curious to know the reasoning behind the reversal, so I can tell if my own support for SOR is wrong-headed. ~TJ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Same Origin Restriction on WOFF fonts across WebKit
On Fri, Jan 28, 2011 at 4:07 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 28, 2011, at 3:44 PM, Adam Barth wrote: On Fri, Jan 28, 2011 at 3:11 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 28, 2011, at 3:06 PM, Tab Atkins Jr. wrote: The WOFF font specification requires that browsers apply Same Origin Restrictions (SOR) to WOFF fonts. So far, Firefox and IE9 follow this requirement, while we and Opera don't. As far as I know, our lack of SOR is basically an accident; we implemented support for WOFF before this requirement was added, and just haven't gotten around to adding it in yet. Chrome people seem amenable to applying SOR to WOFF fonts in Chrome. Is it okay to add this across all our webkit ports? It's not an accident. It has been our intent to willfully ignore this requirement. What's the long-term plan here? Are we hoping the other folks will come around to this point of view eventually? From a game-theory point-of-view, it seems likely that the most permissive behavior is likely to become wide-spread over time. A number of us at Apple who have followed downloadable fonts are not keen on adding pseudo-DRM code to WebKit. That's not the way the Web has worked historically, and there doesn't seem to be a good reason to special-case fonts. It's true that other people have come to the opposite conclusion, but there doesn't seem to be much reason to take their point of view. We also think it's bad to have this requirement in the spec. But we are willing to ignore the spec if it's not changed, as with other specs that we think are a bad idea. I don't think we are too concerned with whether other implementors come around to this idea, since it's unlikely to hurt our compatibility. We think of it as having an extra feature. Bottom line: if there's a strong desire to do this for Chrome, please at least make it switchable so we don't have to enable it for Safari. Thanks for the info. I haven't been following the discussion closely, but I understand that there was some disagreement on this topic. I'm happy to deter to the folks who understand the issue in more detail. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Same Origin Restriction on WOFF fonts across WebKit
On Jan 28, 2011, at 4:10 PM, Tab Atkins Jr. wrote: On Fri, Jan 28, 2011 at 4:07 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 28, 2011, at 3:44 PM, Adam Barth wrote: On Fri, Jan 28, 2011 at 3:11 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 28, 2011, at 3:06 PM, Tab Atkins Jr. wrote: The WOFF font specification requires that browsers apply Same Origin Restrictions (SOR) to WOFF fonts. So far, Firefox and IE9 follow this requirement, while we and Opera don't. As far as I know, our lack of SOR is basically an accident; we implemented support for WOFF before this requirement was added, and just haven't gotten around to adding it in yet. Chrome people seem amenable to applying SOR to WOFF fonts in Chrome. Is it okay to add this across all our webkit ports? It's not an accident. It has been our intent to willfully ignore this requirement. What's the long-term plan here? Are we hoping the other folks will come around to this point of view eventually? From a game-theory point-of-view, it seems likely that the most permissive behavior is likely to become wide-spread over time. A number of us at Apple who have followed downloadable fonts are not keen on adding pseudo-DRM code to WebKit. That's not the way the Web has worked historically, and there doesn't seem to be a good reason to special-case fonts. It's true that other people have come to the opposite conclusion, but there doesn't seem to be much reason to take their point of view. We also think it's bad to have this requirement in the spec. But we are willing to ignore the spec if it's not changed, as with other specs that we think are a bad idea. I don't think we are too concerned with whether other implementors come around to this idea, since it's unlikely to hurt our compatibility. We think of it as having an extra feature. Bottom line: if there's a strong desire to do this for Chrome, please at least make it switchable so we don't have to enable it for Safari. When the webfont discussion started, two years ago on the CSSWG mailing list, Safari appeared to be in favor of SOR http://lists.w3.org/Archives/Public/www-style/2008Oct/0185.html. I'm curious to know the reasoning behind the reversal, so I can tell if my own support for SOR is wrong-headed. I think what I said above roughly summarizes at least my own current thinking. In the earlier discussion you cite, the context was EOT vs. vanilla OTF; WOFF itself hadn't been proposed. At the time, it seemed like a reasonable compromise to adopt same-origin if it would get everyone else to go with OTF and not push EOT on the Web. Microsoft at the time claimed they would never support normal OpenType/TrueType fonts, and it seemed useful to break the logjam. Since then, the situation has changed. Web services have popped up which work around the licensing issues on regular fonts. IE9 is also gaining support for OpenType and TrueType in addition to WOFF. So the reasons for WOFF's creation seem weaker than they ever were. If TrueType fonts with no SOR restriction don't cause the sky to fall, then neither will WOFF fonts with no SOR restriction. We're choosing to support WOFF in Apple's WebKit because it is trivial to do so, but we no longer see same-origin restrictions as useful or necessary. In fact, in some ways it would be better if WOFF itself would go away, since it has no real benefit over other font formats. But it may have too much momentum for that at this point. In addition to this, notwithstanding my 2008-era ill-considered statement, using CORS to relax same-origin restrictions on resource embedding doesn't seem like a good fit. CORS is designed to work around cases where you can't even send the request, and CORS requests are normally sent with no credentials. But we can't reasonably make every font request a proper CORS request, including sending OPTIONS preflight requests to get permission to send credentials. And we don't know the format until after we know the response content type. Looking at CORS headers in a response that is not to a CORS request would break the CORS model and add needless complexity to a security-sensitive technology. It simply muddies the waters to use a cross-site communication technology for DRM purposes instead. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
