date:20081002

On Thu, Oct 2, 2008 at 3:23 AM, Rob Burns [EMAIL PROTECTED] wrote:

 As another drastic anecdotal step, I've turned off javascript on
 Safari (my main browser) and turn to other browsers when I find a site
 that requires javascript. If I don't do that, I find my Macbook Air
 battery eaten away in under an hour just because I left pages open
 that use setTimeout inappropriately.


Safari doesn't have a lower setTimeout() cap than Firefox, so I don't think
this data point is meaningful.

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

Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table

On Wed, Oct 1, 2008 at 10:41 PM, Mike Hommey
[EMAIL PROTECTED][EMAIL PROTECTED]
 wrote:

 On Wed, Oct 01, 2008 at 04:03:32PM -0700, Mike Belshe wrote:
  Total size   Potential savings
  www.cnn.com:   43M
 410Kwww.facebook.com:
   43M 408K
  www.slashdot.org:  36M 208K
  m.ext.google.com:  45M 475K
  docs (normal doc): 42M 341K
  docs (big spreadsheet):55M 905K
  maps:  38M 159K

 It would be interesting to have the figures on 64-bit systems.


Why would it be different, since WebKit is (AFAIK) always compiled in 32-bit
mode?  Or is it 64-bit compat now?

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

Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table

2008-10-02 Thread Sam Weinig

On Thu, Oct 2, 2008 at 8:31 AM, Peter Kasting [EMAIL PROTECTED] wrote:

 On Wed, Oct 1, 2008 at 10:41 PM, Mike Hommey [EMAIL PROTECTED][EMAIL 
 PROTECTED]
  wrote:

 On Wed, Oct 01, 2008 at 04:03:32PM -0700, Mike Belshe wrote:
  Total size   Potential savings
  www.cnn.com:   43M
 410Kwww.facebook.com:
   43M 408K
  www.slashdot.org:  36M 208K
  m.ext.google.com:  45M 475K
  docs (normal doc): 42M 341K
  docs (big spreadsheet):55M 905K
  maps:  38M 159K

 It would be interesting to have the figures on 64-bit systems.


 Why would it be different, since WebKit is (AFAIK) always compiled in
 32-bit mode?  Or is it 64-bit compat now?


WebKit compiles just fine in 64-bit.  We even shiped it 32/64 fat on
Leopard.

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

[webkit-dev] WebKit online benchmarking

2008-10-02 Thread Akos Kiss

Dear WebKit Developers,

Here, at the Department of Software Engineering, University of Szeged, 
we've set up a system for ourselves that does an hourly checkout from 
the SVN of WebKit and measures its performance. This helps us to follow 
the development of WebKit. We think (or at least, we hope) that others 
could also benefit from these hourly measurements, so we created a 
website for this system that can be reached at:

http://www.sed.hu/webkit

For the measurements, we use three benchmarks: SunSpider, the V8 tests 
and a suite of our own, WindScorpion. (A mail on this benchmark was sent 
in August to the list.)

I hope that you will find this helpful. All comments are welcome!

Best regards,

Akos Kiss
Department of Software Engineering
University of Szeged
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WebKit online benchmarking

2008-10-02 Thread Eric Seidel

Neat.

Related, here are the graphs which Chromium uses:
http://build.chromium.org/buildbot/perf/dashboard/overview.html

Those are generated by Google's buildbots.  As you can see there was a
major regression yesterday when we landed the WebKit merge. :)  Our
tree is closed until we fix it.

I like your flash graphs.

-eric

On Thu, Oct 2, 2008 at 10:01 AM, Akos Kiss [EMAIL PROTECTED] wrote:
 Dear WebKit Developers,

 Here, at the Department of Software Engineering, University of Szeged,
 we've set up a system for ourselves that does an hourly checkout from
 the SVN of WebKit and measures its performance. This helps us to follow
 the development of WebKit. We think (or at least, we hope) that others
 could also benefit from these hourly measurements, so we created a
 website for this system that can be reached at:

 http://www.sed.hu/webkit

 For the measurements, we use three benchmarks: SunSpider, the V8 tests
 and a suite of our own, WindScorpion. (A mail on this benchmark was sent
 in August to the list.)

 I hope that you will find this helpful. All comments are welcome!

 Best regards,

 Akos Kiss
 Department of Software Engineering
 University of Szeged
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table


On Oct 1, 2008, at 10:41 PM, Mike Hommey wrote:

 On Wed, Oct 01, 2008 at 04:03:32PM -0700, Mike Belshe wrote:
Total size   Potential savings
 www.cnn.com:   43M  
 410Kwww.facebook.com:
 43M 408K
 www.slashdot.org:  36M 208K
 m.ext.google.com:  45M 475K
 docs (normal doc): 42M 341K
 docs (big spreadsheet):55M 905K
 maps:  38M 159K

 It would be interesting to have the figures on 64-bit systems.

The extra space is all pointers so the size cost would double.

Regards,
Maciej

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

[webkit-dev] Using Google-URL in WebKit

2008-10-02 Thread Brett Wilson

About a year ago, Google released the Google URL Parsing and
Canonicalization Library (Google-URL) as a separate open-source
project: http://code.google.com/p/google-url It was developed for
Chromium with an eye toward being used in other client apps at Google
and elsewhere.

We think there are a number of advantages of this library over the
current KURL code, but I'm not trying to sell anybody on using it or
have a big debate about its merits at this time. (Our most important
constraint is that we want our application layer and our WebKit layer
to agree on parsing for security and other types of mismatch bugs.)

I have mentioned optionally replacing KURL with an ifdef to a number
of WebKit members. The reception has been tentatively yes. There are a
number of reasons to do it:

1. Chromium has this file forked and we can't unfork until at least
the header files are resolved. This prevents us from working as close
to the tip of tree and would probably limit our WebKit contributions.
I would also like to make some changes throughout WebKit that would
help our implementation of KURL, but would also help the current
implementation. This would only be possible if the code was more
unified.

2. It allows the WebKit community to experiment with it. The current
state of affairs is that nobody outside of Google knows much about the
library which prevents detailed technical discussions from taking
place. Even if full adoption of the library never happens, I think
some familiarity with what we did will help future URL parsing and
canonicalization work the WebKit community may approach.

When everybody can try it out then there can be a much better
discussion about whether other ports might want to use it, of the
library's strengths and weaknesses, and possible additions and changes
that people may want to see.

Current state of affairs:

You can see our forked version of KURL.h here:

http://src.chromium.org/viewvc/chrome/trunk/src/webkit/pending/KURL.h?view=markup
Our implementation is here:

http://src.chromium.org/viewvc/chrome/trunk/src/webkit/port/platform/GKURL.cpp?view=markup

http://src.chromium.org/viewvc/chrome/trunk/src/webkit/port/platform/GKURL_unittest.cpp?view=markup

We keep the ability to compile with the Google-URL KURL or the WebCore
KURL (we use this for testing) so the final file in the WebKit tree
would work similarly. You will notice, however, that this file is a
mess and you probably wouldn't want it as-is. It grew organically in
such a way as to minimize the changes relative to the upstream KURL.h.

Proposals/Questions:

I'd like to add the ability to compile KURL using a Google-URL backend
to the WebKit trunk under some kind of #ifdef. The default WebKit
build would see no change in functionality.

1. I don't have any particular preference for the exact ifdef. I think
USE(GOOGLEURL) would be appropriate.

2. I propose to move most of the functions and data additions of our
current KURL.h linked above into a KURLPrivate object which is in
another header file (or KURLGoogleURL.h?). It would be included at the
top of the file controlled by the ifdef. Non Google-URL projects would
just not use this object/header file. This will eliminate most of the
additions while keeping the current code mostly the same. The private
section of the class would look like:
#if USE(GOOGLEURL)
KURLPrivate p;
#else
... current data members.
#endif
I can move the current data into a Private class as well if you
would prefer, which would eliminate further ifdefs but may make it
more difficult to follow.

3. Grouping the other code in our current ifdefs should make more of
the clutter go away. Alternatively, most of the diffs in the header
file (like string getters, isNull, etc.) could be completely
eliminated if the functions were implemented in the .cpp file rather
than inline. I don't think that this would be a performance hit and
would prefer this approach, but others may disagree. There may be some
subset of functions where this makes sense.

4. The Google-URL library would not be checked into WebKit. Those
wishing to use it would install it locally in such a place that
#include googleurl/src/foo.h like Chromium uses now would work.

Comments and questions would be welcome,
Brett
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Using Google-URL in WebKit

2008-10-02 Thread David Hyatt

Kind of an unrelated note, but it would be nice to rename KURL to
something else e.g., WebCoreURL, URL, WebURL, etc.

dave

On Oct 2, 2008, at 3:07 PM, Brett Wilson wrote:

I have mentioned optionally replacing KURL with an ifdef to a number
of WebKit members. The reception has been tentatively yes. There are a
number of reasons to do it:

Current state of affairs:

You can see our forked version of KURL.h here:
http://src.chromium.org/viewvc/chrome/trunk/src/webkit/pending/KURL.h?view=markup
Our implementation is here:
http://src.chromium.org/viewvc/chrome/trunk/src/webkit/port/platform/GKURL.cpp?view=markup
http://src.chromium.org/viewvc/chrome/trunk/src/webkit/port/platform/GKURL_unittest.cpp?view=markup

Proposals/Questions:

I'd like to add the ability to compile KURL using a Google-URL backend
to the WebKit trunk under some kind of #ifdef. The default WebKit
build would see no change in functionality.

1. I don't have any particular preference for the exact ifdef. I think
USE(GOOGLEURL) would be appropriate.

4. The Google-URL library would not be checked into WebKit. Those
wishing to use it would install it locally in such a place that
#include googleurl/src/foo.h like Chromium uses now would work.

Comments and questions would be welcome,
Brett
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] Using Google-URL in WebKit

2008-10-02 Thread Alex Iskander

WURL? Short, but has the required letters -- though perhaps sounds too
funny.

Alex

On Oct 2, 2008, at 3:10 PM, David Hyatt wrote:

Kind of an unrelated note, but it would be nice to rename KURL to
something else e.g., WebCoreURL, URL, WebURL, etc.

dave

On Oct 2, 2008, at 3:07 PM, Brett Wilson wrote:

I have mentioned optionally replacing KURL with an ifdef to a number
of WebKit members. The reception has been tentatively yes. There
are a
number of reasons to do it:

2. It allows the WebKit community to experiment with it. The current
state of affairs is that nobody outside of Google knows much about
the
library which prevents detailed technical discussions from taking
place. Even if full adoption of the library never happens, I think
some familiarity with what we did will help future URL parsing and
canonicalization work the WebKit community may approach.

Current state of affairs:

We keep the ability to compile with the Google-URL KURL or the
WebCore
KURL (we use this for testing) so the final file in the WebKit tree
would work similarly. You will notice, however, that this file is a
mess and you probably wouldn't want it as-is. It grew organically in
such a way as to minimize the changes relative to the upstream
KURL.h.

Proposals/Questions:

I'd like to add the ability to compile KURL using a Google-URL
backend
to the WebKit trunk under some kind of #ifdef. The default WebKit
build would see no change in functionality.

1. I don't have any particular preference for the exact ifdef. I
think
USE(GOOGLEURL) would be appropriate.

2. I propose to move most of the functions and data additions of our
current KURL.h linked above into a KURLPrivate object which is in
another header file (or KURLGoogleURL.h?). It would be included at
the
top of the file controlled by the ifdef. Non Google-URL projects
would
just not use this object/header file. This will eliminate most of the
additions while keeping the current code mostly the same. The private
section of the class would look like:
#if USE(GOOGLEURL)
KURLPrivate p;
#else
... current data members.
#endif
I can move the current data into a Private class as well if you
would prefer, which would eliminate further ifdefs but may make it
more difficult to follow.

4. The Google-URL library would not be checked into WebKit. Those
wishing to use it would install it locally in such a place that
#include googleurl/src/foo.h like Chromium uses now would work.

Comments and questions would be welcome,
Brett
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] Using Google-URL in WebKit

2008-10-02 Thread Brett Wilson

On Thu, Oct 2, 2008 at 1:13 PM, Alex Iskander [EMAIL PROTECTED] wrote:
 WURL? Short, but has the required letters -- though perhaps sounds too
 funny.

We're using GURL which is pretty funny!

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

Re: [webkit-dev] Using Google-URL in WebKit

On Thu, Oct 2, 2008 at 2:23 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:

 I consider the option of completely

replacing WebKit's URL implementation with an external dependency to
 be a nonstarter.


Assume that we wound up in a world where GURL formed the basis of the WebKit
URL implementation.  Does this statement mean you would copy the GURL
sources into the WebKit tree and periodically recopy (kind of like Chromium
does with a number of its dependencies, e.g. libxml, libjpeg, etc.)?  Or
that you would copy once and then ignore upstream (i.e. fork)?  Or that you
would not be willing to even consider basing anything off GURL code unless
it moved from its current repository into the WebKit tree as its sole home
(making it hard for any other project to use it)? Or some other possibility
I've missed?

There are already various dependencies of WebKit on other projects' code
(e.g. sqlite) so I guess I'm trying to figure out how to parse this
statement and whether you're saying that this section of the code is subject
to different requirements.  At least in the Chromium codebase, having pieces
like googleurl be pulled in as external dependencies has not been
problematic at all, and has been useful for other projects.

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

Re: [webkit-dev] Using Google-URL in WebKit

2008-10-02 Thread David Hyatt

It's kind of ridiculous to have an external dependency on a piece of  
code this tiny.


dave

On Oct 2, 2008, at 4:41 PM, Peter Kasting wrote:

On Thu, Oct 2, 2008 at 2:23 PM, Maciej Stachowiak [EMAIL PROTECTED]  
wrote:

I consider the option of completely
replacing WebKit's URL implementation with an external dependency to
be a nonstarter.

Assume that we wound up in a world where GURL formed the basis of  
the WebKit URL implementation.  Does this statement mean you would  
copy the GURL sources into the WebKit tree and periodically recopy  
(kind of like Chromium does with a number of its dependencies, e.g.  
libxml, libjpeg, etc.)?  Or that you would copy once and then ignore  
upstream (i.e. fork)?  Or that you would not be willing to even  
consider basing anything off GURL code unless it moved from its  
current repository into the WebKit tree as its sole home (making it  
hard for any other project to use it)? Or some other possibility  
I've missed?


There are already various dependencies of WebKit on other projects'  
code (e.g. sqlite) so I guess I'm trying to figure out how to parse  
this statement and whether you're saying that this section of the  
code is subject to different requirements.  At least in the Chromium  
codebase, having pieces like googleurl be pulled in as external  
dependencies has not been problematic at all, and has been useful  
for other projects.


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


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

Re: [webkit-dev] Using Google-URL in WebKit

On Thu, Oct 2, 2008 at 2:23 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:


 On Oct 2, 2008, at 1:07 PM, Brett Wilson wrote:

  About a year ago, Google released the Google URL Parsing and
  Canonicalization Library (Google-URL) as a separate open-source
  project: http://code.google.com/p/google-url  It was developed for
  Chromium with an eye toward being used in other client apps at Google
  and elsewhere.
 
  We think there are a number of advantages of this library over the
  current KURL code, but I'm not trying to sell anybody on using it or
  have a big debate about its merits at this time. (Our most important
  constraint is that we want our application layer and our WebKit layer
  to agree on parsing for security and other types of mismatch bugs.)
 
  I have mentioned optionally replacing KURL with an ifdef to a number
  of WebKit members. The reception has been tentatively yes.

 As one of the people who were asked and tentatively said yes, I would
 like to clarify that my agreement was conditional. Specifically, I'm
 ok with this as a temporary measure, as long as we are on track to
 eventually have a unified URL implementation. I think having our long-
 term solution be an ifdef to have two completely separate
 implementations of such a simple class (2000 lines of code for the
 current WebKit implementation) would be extremely silly. Also, we have
 plans to significantly redesign the interface of KURL, and having it
 ifdef'd to two different implementations will make that quite a bit
 harder. Also, the URL code is often a source of security or
 performance issues, and fixing them twice is a cost to the whole
 project.

 To clarify on track to eventually have a unified URL implementation,
 I specifically mean:

 1) The Chromium engineers responsible for this area of code would
 agree in principle that we should work towards a unified URL parsing
 implementation.

 2) We would have at least a rough outline for how the unification
 could happen. I think two plausible approaches are: (a) fix KURL to
 satisfy the requirements that drove the creation of Google-URL and
 drop the Google-URL fork of KURL; (b) integrate Google-URL into the
 WebKit project and drop the original code for KURL. As far as I am
 concerned, both of these options are on the table and the
 determinations should be made by criteria like performance,
 correctness, code quality, etc. I consider the option of completely
 replacing WebKit's URL implementation with an external dependency to
 be a nonstarter.

 3) We would agree on a rough timeline on which we plan to make the
 unification happen; if it hasn't happened by then we'll plan to
 revisit this issue.

 Once we are set on points 1-3, I am ok with landing ifdefs as a
 transitional measure. Until then, I am not ok with such a change.

 Regards,
 Maciej



I agree that it would be very nice to share implementations here.

One thing I'd like to highlight:  It is a requirement for Chromium to use
consistent URL parsing throughout the entire application.  This includes all
processes, the network stack, etc.  While we could invoke KURL to do so, it
is hugely beneficial to us to be able to simply reuse the core elements of
GoogleURL (url_canon, url_parse) via the GURL interface.  So, we end up with
GKURL used by WebCore and GURL used by the rest of Chromium, but both of
those are just thin interface layers around GoogleURL's core.  I think it
would be very awkward (probably a non-starter) for us if we were not able to
separate the KURL interface from the guts and reuse those guts efficiently
in the other parts of our application.  For example, those guts are entirely
parameterized the string type, allowing us to substitute std::string for
WebCore::String, and so on in a very efficient manner.  The core elements of
GoogleURL do not depend on any specific libraries, and that is very
important for our reuse of it throughout our entire application.

Hope this helps clarify why we have what we have.

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

Re: [webkit-dev] Using Google-URL in WebKit



On Oct 2, 2008, at 2:41 PM, Peter Kasting wrote:

On Thu, Oct 2, 2008 at 2:23 PM, Maciej Stachowiak [EMAIL PROTECTED]  
wrote:

I consider the option of completely
replacing WebKit's URL implementation with an external dependency to
be a nonstarter.

Assume that we wound up in a world where GURL formed the basis of  
the WebKit URL implementation.  Does this statement mean you would  
copy the GURL sources into the WebKit tree and periodically recopy  
(kind of like Chromium does with a number of its dependencies, e.g.  
libxml, libjpeg, etc.)?  Or that you would copy once and then ignore  
upstream (i.e. fork)?  Or that you would not be willing to even  
consider basing anything off GURL code unless it moved from its  
current repository into the WebKit tree as its sole home (making it  
hard for any other project to use it)? Or some other possibility  
I've missed?


Something that we had to do extra work to merge periodically would  
probably still seem like effectively an external dependency.




There are already various dependencies of WebKit on other projects'  
code (e.g. sqlite) so I guess I'm trying to figure out how to parse  
this statement and whether you're saying that this section of the  
code is subject to different requirements.  At least in the Chromium  
codebase, having pieces like googleurl be pulled in as external  
dependencies has not been problematic at all, and has been useful  
for other projects.


We tend to use external dependencies when we don't have existing code  
to do the job, where an external library does the job, where the  
amount of code to write it ourselves would be large, and where the  
facility in question does not seem to be core to doing the work of a  
Web browser.


We do not generally replace existing working code with an external  
dependency. We write our own new code rather than using a library when  
the other conditions above are not met.


We are applying these concepts equally to the database code (large,  
complex facility; existing sqlite library does the job; we didn't have  
existing code to implement a SQL database; SQL database is not core to  
a browser) and the URL code (pretty small amount of code; we have  
existing code that works; URL parsing is core to a browser.


Regards,
Maciej

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

Re: [webkit-dev] Using Google-URL in WebKit


On Oct 2, 2008, at 2:53 PM, Darin Fisher wrote:


 I agree that it would be very nice to share implementations here.

 One thing I'd like to highlight:  It is a requirement for Chromium  
 to use consistent URL parsing throughout the entire application.   
 This includes all processes, the network stack, etc.  While we could  
 invoke KURL to do so, it is hugely beneficial to us to be able to  
 simply reuse the core elements of GoogleURL (url_canon, url_parse)  
 via the GURL interface.  So, we end up with GKURL used by WebCore  
 and GURL used by the rest of Chromium, but both of those are just  
 thin interface layers around GoogleURL's core.  I think it would be  
 very awkward (probably a non-starter) for us if we were not able to  
 separate the KURL interface from the guts and reuse those guts  
 efficiently in the other parts of our application.  For example,  
 those guts are entirely parameterized the string type, allowing us  
 to substitute std::string for WebCore::String, and so on in a very  
 efficient manner.  The core elements of GoogleURL do not depend on  
 any specific libraries, and that is very important for our reuse of  
 it throughout our entire application.

 Hope this helps clarify why we have what we have.

I'd be open to WebCore exporting a more general or lower-level URL  
interface that is more readily usable from non-WebCore contexts, if  
KURL does not suit as-is.

I should also note that, originally, our KURL was a wrapper on top of  
NSURL, since the app level and network layer for the Mac port use  
NSURL. We decided to drop that in favor of cross-platform code, and  
convert to NSURL as the boundaries. As far as I know, we have not had  
serious problems from mismatches, whether security or otherwise.

Regards,
Maciej

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

Re: [webkit-dev] Using Google-URL in WebKit

2008-10-02 Thread Geoffrey Garen

 One thing I'd like to highlight:  It is a requirement for Chromium  
 to use consistent URL parsing throughout the entire application.

Can you explain this requirement more?

I think that's an important data point, since other WebKit ports,  
including the Mac port, use KURL in WebKit and a different URL class  
in the app / platform layers -- so we may not be sufficiently familiar  
with why a single URL class is so important to Chrome.

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

Re: [webkit-dev] Using Google-URL in WebKit

On Thu, Oct 2, 2008 at 3:01 PM, Geoffrey Garen [EMAIL PROTECTED] wrote:

 One thing I'd like to highlight:  It is a requirement for Chromium to use
 consistent URL parsing throughout the entire application.


 Can you explain this requirement more?

 I think that's an important data point, since other WebKit ports, including
 the Mac port, use KURL in WebKit and a different URL class in the app /
 platform layers -- so we may not be sufficiently familiar with why a single
 URL class is so important to Chrome.



Sure.  It helps us avoid security bugs that may be caused by inconsistent
URL handling in different parts of the code base.  This is very important to
us.

For example, canonicalization effects whether you consider two URL strings
to be the same or different.  This can impact the network stack, the
download manager, the URL bar, the safe browsing system, the history system,
etc. etc.  In some cases it is just about correctness.  In others it is
about security.

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

Re: [webkit-dev] Using Google-URL in WebKit

On Thu, Oct 2, 2008 at 3:27 PM, David Hyatt [EMAIL PROTECTED] wrote:

 On Oct 2, 2008, at 4:23 PM, Maciej Stachowiak wrote:

 
  I have mentioned optionally replacing KURL with an ifdef to a number
  of WebKit members. The reception has been tentatively yes.
 
  As one of the people who were asked and tentatively said yes,

 I am strongly against integration of GURL behind KURL.  This code is
 simple, and there's no reason to complicate it like this.  Any port
 should be able to use KURL as is and just translate at boundaries
 (like the existing Mac port does).  I don't think there should be any
 major issues with this approach, and the alternative is to place a
 burden on WebKit as far as having to maintain a now needlessly
 complicated KURL class.



Hi Dave,

Please see my comments on this thread.  Summarizing:  The code for correct
and complete URL parsing / canonicalization is non-trivial and in many cases
extremely subtle.  It is important to Chromium to use consistent URL
handling across the entire application.  For example, our network stack
depends on GoogleURL.  We have strong desire to share the same URL handling
code with WebCore so that we achieve consistency, avoiding both correctness
and security bugs.  It would be awkward to have our otherwise independent
network stack suddenly depend on WebCore.

All we are asking for is to add a couple #ifdefs to KURL.h so that we do not
have to maintain a fork.  Is that really so hard to maintain going forward?
 We are happy to do all of the work to maintain it.

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

Re: [webkit-dev] Using Google-URL in WebKit

2008-10-02 Thread David Hyatt


On Oct 2, 2008, at 5:35 PM, Darin Fisher wrote:


On Thu, Oct 2, 2008 at 3:27 PM, David Hyatt [EMAIL PROTECTED] wrote:
On Oct 2, 2008, at 4:23 PM, Maciej Stachowiak wrote:


 I have mentioned optionally replacing KURL with an ifdef to a  
number

 of WebKit members. The reception has been tentatively yes.

 As one of the people who were asked and tentatively said yes,

I am strongly against integration of GURL behind KURL.  This code is
simple, and there's no reason to complicate it like this.  Any port
should be able to use KURL as is and just translate at boundaries
(like the existing Mac port does).  I don't think there should be any
major issues with this approach, and the alternative is to place a
burden on WebKit as far as having to maintain a now needlessly
complicated KURL class.


Hi Dave,

Please see my comments on this thread.  Summarizing:  The code for  
correct and complete URL parsing / canonicalization is non-trivial  
and in many cases extremely subtle.  It is important to Chromium to  
use consistent URL handling across the entire application.  For  
example, our network stack depends on GoogleURL.  We have strong  
desire to share the same URL handling code with WebCore so that we  
achieve consistency, avoiding both correctness and security bugs.   
It would be awkward to have our otherwise independent network stack  
suddenly depend on WebCore.


All we are asking for is to add a couple #ifdefs to KURL.h so that  
we do not have to maintain a fork.  Is that really so hard to  
maintain going forward?  We are happy to do all of the work to  
maintain it.




I would be ok with this if you don't place a burden on the other five  
ports to keep your version of KURL working.  In other words, if the  
API for KURL needs to be changed, it would be Google's responsibility  
to keep their GURL-backed version working.  That means checkins to  
KURL to change the API could break you going forward.  If you are ok  
with this, then I am ok with this.


dave
([EMAIL PROTECTED])

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

Re: [webkit-dev] Using Google-URL in WebKit



On Oct 2, 2008, at 3:43 PM, David Hyatt wrote:


On Oct 2, 2008, at 5:35 PM, Darin Fisher wrote:


On Thu, Oct 2, 2008 at 3:27 PM, David Hyatt [EMAIL PROTECTED] wrote:
On Oct 2, 2008, at 4:23 PM, Maciej Stachowiak wrote:


 I have mentioned optionally replacing KURL with an ifdef to a  
number

 of WebKit members. The reception has been tentatively yes.

 As one of the people who were asked and tentatively said yes,

I am strongly against integration of GURL behind KURL.  This code is
simple, and there's no reason to complicate it like this.  Any port
should be able to use KURL as is and just translate at boundaries
(like the existing Mac port does).  I don't think there should be any
major issues with this approach, and the alternative is to place a
burden on WebKit as far as having to maintain a now needlessly
complicated KURL class.


Hi Dave,

Please see my comments on this thread.  Summarizing:  The code for  
correct and complete URL parsing / canonicalization is non-trivial  
and in many cases extremely subtle.  It is important to Chromium to  
use consistent URL handling across the entire application.  For  
example, our network stack depends on GoogleURL.  We have strong  
desire to share the same URL handling code with WebCore so that we  
achieve consistency, avoiding both correctness and security bugs.   
It would be awkward to have our otherwise independent network stack  
suddenly depend on WebCore.


All we are asking for is to add a couple #ifdefs to KURL.h so that  
we do not have to maintain a fork.  Is that really so hard to  
maintain going forward?  We are happy to do all of the work to  
maintain it.




I would be ok with this if you don't place a burden on the other  
five ports to keep your version of KURL working.  In other words, if  
the API for KURL needs to be changed, it would be Google's  
responsibility to keep their GURL-backed version working.  That  
means checkins to KURL to change the API could break you going  
forward.  If you are ok with this, then I am ok with this.


I would rather we seriously look at a way to unfork the URL parsing  
code, before discussing mechanics of how to keep it forked. We don't  
normally put ifdef paths in core code in WebKit that the WebKit  
project is not expected to maintain, so that certainly wouldn't be my  
first choice. And I do believe it will waste people's time to have the  
fork there even if there is a prominent notice that Google is expected  
to do all the work to keep it working.


Regards,
Maciej

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

Re: [webkit-dev] Using Google-URL in WebKit

2008-10-02 Thread Geoffrey Garen

 KURL  depends on WebCore types, and was
 found to have bugs, so Brett did a study of other URL parsers and
 wrote the Google URL library as a template library (and wrote GURL as
 an example class using it with std::string).

This part I don't get. Brett found some bugs. Why didn't he fix them?  
Did he file them, at least? Isn't that what participating in an open  
source project is all about?

If Brett finds some bugs in layout and rendering, is head going to  
write a GCSS?

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

Re: [webkit-dev] Using Google-URL in WebKit

On Thu, Oct 2, 2008 at 3:49 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:

 I would rather we seriously look at a way to unfork the URL parsing code,
 before discussing mechanics of how to keep it forked. We don't normally put
 ifdef paths in core code in WebKit that the WebKit project is not expected
 to maintain, so that certainly wouldn't be my first choice. And I do believe
 it will waste people's time to have the fork there even if there is a
 prominent notice that Google is expected to do all the work to keep it
 working.


We're trying to join the WebKit community as ongoing contributors, not dump
work in your lap and run away (or even dump work in our own laps but stand
apart from you).  The WebKit community _would be_ expected to maintain these
paths-- we're volunteering to do it as WebKit contributors and, hopefully,
members of that community.  The sooner it can stop being WebKit As Opposed
To Google and start being all of us working together on making WebKit
better, the better, IMO.

And obviously we share your desire not to have two implementations long
term.  We're trying to work with you to avoid that; we already have it right
now, it just exists as a fork of the WebKit tree into our tree, which is IMO
even worse than ifdefs.

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

Re: [webkit-dev] Using Google-URL in WebKit

On Thu, Oct 2, 2008 at 3:43 PM, David Hyatt [EMAIL PROTECTED] wrote:

 On Oct 2, 2008, at 5:35 PM, Darin Fisher wrote:

 On Thu, Oct 2, 2008 at 3:27 PM, David Hyatt [EMAIL PROTECTED] wrote:

 On Oct 2, 2008, at 4:23 PM, Maciej Stachowiak wrote:

 
  I have mentioned optionally replacing KURL with an ifdef to a number
  of WebKit members. The reception has been tentatively yes.
 
  As one of the people who were asked and tentatively said yes,

 I am strongly against integration of GURL behind KURL.  This code is
 simple, and there's no reason to complicate it like this.  Any port
 should be able to use KURL as is and just translate at boundaries
 (like the existing Mac port does).  I don't think there should be any
 major issues with this approach, and the alternative is to place a
 burden on WebKit as far as having to maintain a now needlessly
 complicated KURL class.



 Hi Dave,

 Please see my comments on this thread.  Summarizing:  The code for correct
 and complete URL parsing / canonicalization is non-trivial and in many cases
 extremely subtle.  It is important to Chromium to use consistent URL
 handling across the entire application.  For example, our network stack
 depends on GoogleURL.  We have strong desire to share the same URL handling
 code with WebCore so that we achieve consistency, avoiding both correctness
 and security bugs.  It would be awkward to have our otherwise independent
 network stack suddenly depend on WebCore.

 All we are asking for is to add a couple #ifdefs to KURL.h so that we do
 not have to maintain a fork.  Is that really so hard to maintain going
 forward?  We are happy to do all of the work to maintain it.


 I would be ok with this if you don't place a burden on the other five ports
 to keep your version of KURL working.  In other words, if the API for KURL
 needs to be changed, it would be Google's responsibility to keep their
 GURL-backed version working.  That means checkins to KURL to change the API
 could break you going forward.  If you are ok with this, then I am ok with
 this.



Yup, we would not expect anyone else to be responsible for the #ifdefs that
we introduce into WebKit.  Long-term, I'd really prefer not to have #ifdefs
at all in WebCore.  I'd rather work toward an abstraction that avoids them
(without performance overhead of course).  I think we can do that here, but
it is important to walk before running, and so the #ifdef is very helpful as
a starting point.

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

Re: [webkit-dev] Using Google-URL in WebKit

On Thu, Oct 2, 2008 at 3:53 PM, Geoffrey Garen [EMAIL PROTECTED] wrote:

 KURL  depends on WebCore types, and was
 found to have bugs, so Brett did a study of other URL parsers and
 wrote the Google URL library as a template library (and wrote GURL as
 an example class using it with std::string).


 This part I don't get. Brett found some bugs. Why didn't he fix them? Did
 he file them, at least? Isn't that what participating in an open source
 project is all about?

 If Brett finds some bugs in layout and rendering, is head going to write a
 GCSS?



I explained this on #webkit, but since that was easy to miss... we did not
build GoogleURL because we thought KURL was buggy.  We built GoogleURL
because we needed to have consistent URL parsing and canonicalization
throughout our entire application, including our network stack, download
manager, and user interface.  It was not until later that we went the full
distance and wrote GKURL (again because we wanted to have consistent URL
parsing and canonicalization throughout our entire application).  We did our
best to make GoogleURL match the quirks of Internet Explorer except in
places where that did not make sense.  Some of those behaviors may be
interesting or may even be regarded as good RFE bugs for KURL, but they are
not the reasons for GoogleURL's existence.

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

Re: [webkit-dev] Long-term Google-URL integration plans


This plan seems generally ok, a few comments:

On Oct 2, 2008, at 4:43 PM, Brett Wilson wrote:

 I posted earlier about adding an ifdef for the Google-URL library in
 KURL.h. I thought I would also explain the current thinking on the
 long term plans, which a number of people have expressed concern
 about. The current ifdef approach is an incremental way for us to move
 forward, both with out merge of forked WebCore files, and toward a
 more unified URL handling infrastructure.

 We are open to a wide variety of solutions. We have a requirement that
 we can use the same backend for our application-layer URL handling
 without adding WebKit types. It would need to have two modes: a 16-bit
 character mode for web pages, and an 8-bit character mode for
 interpreting network traffic. Where the code lives and what format the
 code is in are less important.

 I think the best goal to have at this point that satisfies everybody's
 requirements is that there be an interface layer that KURL uses. This
 interface would basically be the url_canon and url_parse interfaces in
 Google-URL. The initial implementation of these interfaces would be
 the Google-URL code, and they would live in some directory inside
 WebKit in the WebKit coding style.

I'd like to not assume up front that the code used to implement the  
URL parsing core will be Google-URL. Maybe Google-URL's code will turn  
out to be better, maybe the current KURL implementation will. I'm  
willing to keep an open mind about this until we can do some  
comparisons. Are you also willing to keep an open mind about which  
implementation is the basis of a shared one?

I also do not find the current interfaces of url_canon or url_parse  
particularly congenial, so we should also keep an open mind on what  
the interface to this code would look like. Is that ok with you?

 This code would have no WebCore, WTF, or STL types in it.

I'd like to relax this and say WTF types should be ok as long as they  
are moved to the same dependency level and have an equally liberal  
license. For instance, I don't see the win of the URL library having a  
separate class for a resizable buffer with possible stack backing  
store for small buffers, rather than using WTF::Vector. Similarly, if  
any unicode processing is needed, it would be nice to use WTF's  
unicode library abstraction layer for ports that do not use ICU but  
have a different source of unicode functionality (I think that's only  
the Qt port currently).

 Applications like Chromium could (if they wanted)) implement their  
 own URL objects
 on top of this interface, just like KURL would be implemented on top
 of it. Other applications could also use this code without taking a
 dependency on WebKit (there has been some interest expressed about
 Google-URL for this reason). This is basically splitting the current
 library into two, along layers which are already designed into it
 (with the exception of one std::vector in url_util.cc which is a bug).
 The current Google-URL project would likely be abandoned.

 The WebKit community currently has little knowledge about this library
 today. Predicting the final outcome will be impossible until the
 community has some experience with this code. They may find that the
 code or approach of the library is unacceptable, and we'll have to
 find another way forward. Assuming that the Google-URL library is
 largely seen as an improvement to the codebase by the WebKit
 community, what I have outlined here would be a perfectly acceptable
 solution to us.

I have a copy of the library checked out from SVN (have for quite some  
time) and I have studied the code. But I will admit I don't know much  
about how well it works.

Anyway, I am ok with this something along these lines with the caveats  
mentioned above.

Does anyone else have comments?

Regards,
Maciej

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

[webkit-dev] High Resolution Timer API proposal(s)


I'm going to send this along to the relevant fora (not sure if it  
should be part of HTML5 or a separate Web Apps WG spec), but here's  
some rough API ideas:


Ridiculously minimalist version:

void callSoon(Function callback);

- Calls the function callback with no arguments the next time  
processing returns to the event loop as if it were a timer ready to  
fire.

To break up work with event processing you'd do:
callSoon(continueFunc);



Fairly minimalist version:

Timer startTimer(double delayInSeconds, bool repeating, Function  
callback);

interface Timer {
 void stop();
}


- Starts a timer that will call function callback after  
delayInSeconds, which may be a fractional number of seconds. If  
repeating is true, the timer will fire periodically at every  
delayInSeconds. User agents should try to fire timers as close to the  
true delay time as they can, and in particular if the delay is 0 the  
timer should be considered ready to fire on the next return to the  
event loop.


To break up work with event processing you'd do:
startTimer(0, false, continueFunc);



Overengineered version:

Timer createTimer(double firstInterval, double repeatInterval, long  
repeatCount);

interface Timer : EventTarget {
 void stop();
 void start();
 void pause();
 void resume();
 readonly attribute bool isRunning;
 readonly attribute bool isPaused;
 readonly attribute Date startDate;
 double firstInterval;
 double repeatInterval;
 double timeRemaining;
 long repeatCount;
 long repeatsRemaining;
};

- fires event named timer when the timer is ready to fire.

To break up work with event processing you'd do:
var timer = createTimer(0, 0, 1);
timer.addEventListener(timer, continueFunc, false);
timer.start();


I don't really like the overengineered version. I like the fairly  
minimalist version best, but is there anything from the  
overengineered version that should be added to it?

I'll probably propose something like the fairly minimalist version to  
HTML5.

Regards,
Maciej

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

Re: [webkit-dev] Proposed Timer API


On Oct 1, 2008, at 9:11 PM, Cameron McCormack wrote:

 Justin Haygood:
 http://blog.justinhaygood.com/2008/09/30/proposed-high-resolution-timer-api/

 If possible, it would be nice if there could be some degree of
 compatibility between this proposed API and the one in SVG Tiny 1.2:

  http://dev.w3.org/SVG/profiles/1.2T/publish/ 
 svgudom.html#svg__SVGTimer

 Though I imagine you don’t want to fire events called SVGTimer. :)

I considered that, but I don't like the fact that it makes the common  
zero-delay continuation callback case into three lines of code instead  
of one, for what I think is no practical benefit.

Regards,
Maciej

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

Re: [webkit-dev] High Resolution Timer API proposal(s)

On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
 I don't really like the overengineered version. I like the fairly
 minimalist version best, but is there anything from the
 overengineered version that should be added to it?

I like the fairly minimalist version best as well.

The stop() method does seem a little lonely on the Timer interface all
by itself.

If others think any other members from the overengineered version
are important I would welcome them to keep stop() company.

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

Re: [webkit-dev] Long-term Google-URL integration plans

2008-10-02 Thread Brett Wilson

On Thu, Oct 2, 2008 at 4:58 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
 I also do not find the current interfaces of url_canon or url_parse
 particularly congenial, so we should also keep an open mind on what the
 interface to this code would look like. Is that ok with you?

Some background: url_parse and url_canon are designed to be very
low-level and flexible. They are not actually intended to be used
directly by an application. They are intended to be used by a wrapper
object that can be written using any generic string type, 8- or 16-bit
string inputs. The current interface certainly isn't perfect, but I
think it's about what you get with these requirements.

On top of this layer is the url_util layer. This is what GURL and KURL
are really implemented in terms of, and it's actually quite simple. It
calls the correct lower-level functions in the ways that they were
intended to be called. Sometimes it's convenient to bypass this, and
we occationally do. It's nice that the application has the option to
do either.

You can see the GURL object has both a relatively clean interface and
relatively little logic inside of it.

As you say, the exact interface to the lower layers is unimportant as
long as it meets the needs of both objects.


 This code would have no WebCore, WTF, or STL types in it.

 I'd like to relax this and say WTF types should be ok as long as they are
 moved to the same dependency level and have an equally liberal license. For
 instance, I don't see the win of the URL library having a separate class for
 a resizable buffer with possible stack backing store for small buffers,
 rather than using WTF::Vector. Similarly, if any unicode processing is
 needed, it would be nice to use WTF's unicode library abstraction layer for
 ports that do not use ICU but have a different source of unicode
 functionality (I think that's only the Qt port currently).

 Applications like Chromium could (if they wanted)) implement their own URL
 objects
 on top of this interface, just like KURL would be implemented on top
 of it. Other applications could also use this code without taking a
 dependency on WebKit (there has been some interest expressed about
 Google-URL for this reason). This is basically splitting the current
 library into two, along layers which are already designed into it
 (with the exception of one std::vector in url_util.cc which is a bug).
 The current Google-URL project would likely be abandoned.

 The WebKit community currently has little knowledge about this library
 today. Predicting the final outcome will be impossible until the
 community has some experience with this code. They may find that the
 code or approach of the library is unacceptable, and we'll have to
 find another way forward. Assuming that the Google-URL library is
 largely seen as an improvement to the codebase by the WebKit
 community, what I have outlined here would be a perfectly acceptable
 solution to us.

 I have a copy of the library checked out from SVN (have for quite some time)
 and I have studied the code. But I will admit I don't know much about how
 well it works.

I think when you can run it in Safari, you'll feel more strongly about
it one way or the other :)


[moved from the beginning of the message]
 I'd like to not assume up front that the code used to implement the URL
 parsing core will be Google-URL. Maybe Google-URL's code will turn out to be
 better, maybe the current KURL implementation will. I'm willing to keep an
 open mind about this until we can do some comparisons. Are you also willing
 to keep an open mind about which implementation is the basis of a shared
 one?

You should not be accepting this code because you're doing a favor for
us. You should accept it because you think that there's a good chance
you will eventually end up with a better URL implementation. If you
don't think this is the case, please let me know. I would rather spend
my efforts maintaining a fork of KURL than arguing about why you
should do something you don't want. I've probably spent only one day
all year merging KURL, so the status quo will be significantly less
work for me personally.

If we check it in with ifdefs, you evaluate the details of the
implementation, and you think that the current KURL code is better
than Google-URL, then I think this status quo is easier for both of
us. Nothing precludes this from happening. This is why I was very
clear about evaluation and that you may find it unacceptable,
which is OK. I will volunteer to do the work necessary to factor the
code as necessary if you decide you like it.

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

Re: [webkit-dev] High Resolution Timer API proposal(s)

On Thu, Oct 2, 2008 at 5:32 PM, Ojan Vafai [EMAIL PROTECTED] wrote:

 On Thu, Oct 2, 2008 at 5:16 PM, Aaron Boodman [EMAIL PROTECTED] wrote:

 On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
  I don't really like the overengineered version. I like the fairly
  minimalist version best, but is there anything from the
  overengineered version that should be added to it?

 I like the fairly minimalist version best as well.

 The stop() method does seem a little lonely on the Timer interface all
 by itself.

 If others think any other members from the overengineered version
 are important I would welcome them to keep stop() company.


 +1. My ideal would be the following:

 Timer startTimer(double delayInSeconds, bool repeating, Function callback);

 interface Timer {
 void stop();
 void resume();
 void setDelay(double delayInSeconds);
 }

 That would cover the majority of cases I've seen in real-world javascript
 code. The argument for setDelay is wanting to be able to tweak the delay on
 the fly (e.g. Google Page Creator has autosave code that gets a response
 from the server  with a longer delay time when the server is overloaded).


That is a good use case.  Adjusting the delay can often be optimized down to
just re-positioning the already pending timeout in a priority queue.

Would it make sense for resume and setDelay to be combined as a
restart(delayInSeconds) method, perhaps where delayInSeconds is an optional
parameter?

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

[webkit-dev] Database Storage

2008-10-02 Thread Loll

Hi,

Im not sure if this is the right place to ask this or not, so im sorry  
in advance if it is.

I am interested in the database Storage that is now available through  
webkit and had a few questions about it.

My main point of interest is in the security of it. Right now, the  
website I develop uses PHP and information is stored using PHP  
sessions. From a servers point of view I can see a lot of advantages  
of storing such data locally. For one thing , its lot less reads and  
writes to the server, making it a bit faster I would expect.

But how secure is the data? is it secure enough to reliably put such  
info on a clients system? Im not talking about bank data here, but I  
am looking at data that I would not want to be altered or viewed in  
its raw format all the same.

Is it safe to assume that no one is going to get into it , any more  
than its safe to assume that no one is going to hijack a PHP Session  
to gain access to the same data?

Anyway I just wondered if was a good idea to think about moving in the  
direction of local storage vs server storage and what level of data  
should be safely stored that way, vs what shouldn't be stored that way.

Thanks

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

Re: [webkit-dev] High Resolution Timer API proposal(s)

2008-10-02 Thread Timothy Hatcher


Why double delayInSeconds and not milliseconds to stay consistent?

On Oct 2, 2008, at 5:32 PM, Ojan Vafai wrote:


On Thu, Oct 2, 2008 at 5:16 PM, Aaron Boodman [EMAIL PROTECTED] wrote:
On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak [EMAIL PROTECTED]  
wrote:

 I don't really like the overengineered version. I like the fairly
 minimalist version best, but is there anything from the
 overengineered version that should be added to it?

I like the fairly minimalist version best as well.

The stop() method does seem a little lonely on the Timer interface all
by itself.

If others think any other members from the overengineered version
are important I would welcome them to keep stop() company.

+1. My ideal would be the following:

Timer startTimer(double delayInSeconds, bool repeating, Function  
callback);


interface Timer {
void stop();
void resume();
void setDelay(double delayInSeconds);
}

That would cover the majority of cases I've seen in real-world  
javascript code. The argument for setDelay is wanting to be able to  
tweak the delay on the fly (e.g. Google Page Creator has autosave  
code that gets a response from the server  with a longer delay time  
when the server is overloaded).


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


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

Re: [webkit-dev] High Resolution Timer API proposal(s)

On a separate thread, it was discussed that it is useful to support
microsecond resolution for future proofness.
-Darin


On Thu, Oct 2, 2008 at 5:53 PM, Timothy Hatcher [EMAIL PROTECTED]wrote:

 Why double delayInSeconds and not milliseconds to stay consistent?

 On Oct 2, 2008, at 5:32 PM, Ojan Vafai wrote:

 On Thu, Oct 2, 2008 at 5:16 PM, Aaron Boodman [EMAIL PROTECTED] wrote:

 On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
  I don't really like the overengineered version. I like the fairly
  minimalist version best, but is there anything from the
  overengineered version that should be added to it?

 I like the fairly minimalist version best as well.

 The stop() method does seem a little lonely on the Timer interface all
 by itself.

 If others think any other members from the overengineered version
 are important I would welcome them to keep stop() company.


 +1. My ideal would be the following:

 Timer startTimer(double delayInSeconds, bool repeating, Function callback);

 interface Timer {
 void stop();
 void resume();
 void setDelay(double delayInSeconds);
 }

 That would cover the majority of cases I've seen in real-world javascript
 code. The argument for setDelay is wanting to be able to tweak the delay on
 the fly (e.g. Google Page Creator has autosave code that gets a response
 from the server  with a longer delay time when the server is overloaded).

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



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


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

Re: [webkit-dev] High Resolution Timer API proposal(s)



On Oct 2, 2008, at 5:28 PM, Ojan Vafai wrote:


On Thu, Oct 2, 2008 at 5:16 PM, Aaron Boodman [EMAIL PROTECTED] wrote:
On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak [EMAIL PROTECTED]  
wrote:

 I don't really like the overengineered version. I like the fairly
 minimalist version best, but is there anything from the
 overengineered version that should be added to it?

I like the fairly minimalist version best as well.

The stop() method does seem a little lonely on the Timer interface all
by itself.

If others think any other members from the overengineered version
are important I would welcome them to keep stop() company.

+1. My ideal would be the following:

Timer startTimer(double delayInSeconds, bool repeating, Function  
callback);


interface Timer {
void stop();
void resume();
void setDelay(double delayInSeconds);
}


What would you expect the resume() method to do (since there is no  
pause)?




That would cover the majority of cases I've seen in real-world  
javascript code. The argument for setDelay is wanting to be able to  
tweak the delay on the fly (e.g. Google Page Creator has autosave  
code that gets a response from the server  with a longer delay time  
when the server is overloaded).


I briefly considered cases like that, but I thought it seemed simple  
enough to just cancel the existing timer and start a new one. And it  
seemed uncommon enough to me that it didn't need a direct affordance  
in the API instead of just making a new timer.


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

Re: [webkit-dev] Proposed Timer API

2008-10-02 Thread Cameron McCormack

Hi Maciej.

Cameron McCormack:
  If possible, it would be nice if there could be some degree of
  compatibility between this proposed API and the one in SVG Tiny 1.2:
 
   http://dev.w3.org/SVG/profiles/1.2T/publish/svgudom.html#svg__SVGTimer

Maciej Stachowiak:
 I considered that, but I don't like the fact that it makes the common  
 zero-delay continuation callback case into three lines of code instead  
 of one, for what I think is no practical benefit.

Justin’s proposed API seems to need four lines for that case:

  var t = new Timer();
  t.repeatCount = 1;
  t.addEventListener('timercomplete', function() { … }, false);
  t.start();

compared with the three for SVG’s timer:

  var t = createTimer(0, -1);
  t.addEventListener('SVGTimer', function() { … }, false);
  t.start();

Or do you mean compared to a simple function-like API, such as
setTimeout(), where it can be done in one line?  (Perhaps functions like
setHighResolution{Interval,Timeout}() would be easiest then.)

-- 
Cameron McCormack ≝ http://mcc.id.au/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] High Resolution Timer API proposal(s)

On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
 - Starts a timer that will call function callback after
 delayInSeconds, which may be a fractional number of seconds.

It seems safe to assume that a large number of timers are going to be
on the order of 1-10ms. Because of this I think that millisecond units
(which can also be fractional) would be best. It also is nice because
it is consistent with the current API.

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

Re: [webkit-dev] High Resolution Timer API proposal(s)



On Oct 2, 2008, at 5:58 PM, Darin Fisher wrote:

On a separate thread, it was discussed that it is useful to support  
microsecond resolution for future proofness.


I proposed seconds so that it was more clear that fractional versions  
could be used, and because specifying microseconds as fractional  
milliseconds seems awkward to me. But whatever the baseline  
resolution, I think fractional values should be supported so there  
isn't an artificial floor to the resolution on future hardware.


 - Maciej



-Darin


On Thu, Oct 2, 2008 at 5:53 PM, Timothy Hatcher  
[EMAIL PROTECTED] wrote:

Why double delayInSeconds and not milliseconds to stay consistent?

On Oct 2, 2008, at 5:32 PM, Ojan Vafai wrote:


On Thu, Oct 2, 2008 at 5:16 PM, Aaron Boodman [EMAIL PROTECTED] wrote:
On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak [EMAIL PROTECTED]  
wrote:

 I don't really like the overengineered version. I like the fairly
 minimalist version best, but is there anything from the
 overengineered version that should be added to it?

I like the fairly minimalist version best as well.

The stop() method does seem a little lonely on the Timer interface  
all

by itself.

If others think any other members from the overengineered version
are important I would welcome them to keep stop() company.

+1. My ideal would be the following:

Timer startTimer(double delayInSeconds, bool repeating, Function  
callback);


interface Timer {
void stop();
void resume();
void setDelay(double delayInSeconds);
}

That would cover the majority of cases I've seen in real-world  
javascript code. The argument for setDelay is wanting to be able to  
tweak the delay on the fly (e.g. Google Page Creator has autosave  
code that gets a response from the server  with a longer delay time  
when the server is overloaded).


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



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


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


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

Re: [webkit-dev] Long-term Google-URL integration plans


On Oct 2, 2008, at 5:28 PM, Brett Wilson wrote:


 [moved from the beginning of the message]
 I'd like to not assume up front that the code used to implement the  
 URL
 parsing core will be Google-URL. Maybe Google-URL's code will turn  
 out to be
 better, maybe the current KURL implementation will. I'm willing to  
 keep an
 open mind about this until we can do some comparisons. Are you also  
 willing
 to keep an open mind about which implementation is the basis of a  
 shared
 one?

 You should not be accepting this code because you're doing a favor for
 us. You should accept it because you think that there's a good chance
 you will eventually end up with a better URL implementation. If you
 don't think this is the case, please let me know. I would rather spend
 my efforts maintaining a fork of KURL than arguing about why you
 should do something you don't want. I've probably spent only one day
 all year merging KURL, so the status quo will be significantly less
 work for me personally.

It sounds to me like you are saying that you would not be willing to  
consider using the current KURL implementation in Chrome, even it  
turns out to be materially better, and it gets exposed with a low- 
level interface that you could use in non-WebCore pieces of Chrome,  
and ends up free of problematic dependencies or license terms.

Is that a correct interpretation of what you are saying?

Regards,
Maciej

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

Re: [webkit-dev] High Resolution Timer API proposal(s)

On Thu, Oct 2, 2008 at 5:59 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:

 I briefly considered cases like that, but I thought it seemed simple enough
 to just cancel the existing timer and start a new one. And it seemed
 uncommon enough to me that it didn't need a direct affordance in the API
 instead of just making a new timer.


The counter-use case I would have would be wanting to lengthen a timer
that's already running; e.g. you set a timer for 1 second, and at some point
while it's waiting to go off you realize you need to lengthen it to 2
seconds.  If you have to cancel and reset, you also have to track separately
just how much time has elapsed so you know how to do this.

On Thu, Oct 2, 2008 at 6:06 PM, Aaron Boodman [EMAIL PROTECTED] wrote:

 It seems safe to assume that a large number of timers are going to be
 on the order of 1-10ms. Because of this I think that millisecond units
 (which can also be fractional) would be best. It also is nice because
 it is consistent with the current API.


Most of the setTimeout()/setInterval() calls I saw in surveying the web the
other day were for some round fraction of a second: 0.1, 0.5, 1, or 2
seconds.  I don't think this would change too much.  And fractional seconds
doesn't make my head hurt the way fractional milliseconds does.

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

Re: [webkit-dev] High Resolution Timer API proposal(s)


On Oct 2, 2008, at 6:14 PM, Ojan Vafai wrote:

 The thing is that often enough the place where you want to modify  
 the delay you don't necessarily have access to the callback you  
 would need in order to recreate the timer. So, you have to keep  
 track of more stuff in JavaScript (e.g. a pointer to the callback).  
 It's not the end of the world, but it makes for clunkier uses of the  
 API.

 What do you think of the following?

 interface Timer {
 void stop();
 void restart(double optional_argument_delayInSeconds);
 }

Would restart change the time remaining as if that delay had been set  
originally, or would it make the new delay the current time remaining?  
Should it also let you change the repeating status of the timer? (That  
doesn't seem hugely important but this way seems oddly non-orthogonal).

Perhaps there should be a timeElapsed field (which would give seconds  
actually elapsed since last fire, to the best precision the UA can  
manage), which is useful for both recalculating delays and adjusting  
for jitter.

I think I will post it to a standards group soon, probably starting  
with whatwg and possibly moving to webapps if Hixie thinks that is the  
right way to go. We can discuss details further there.

Regards,
Maciej

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

Re: [webkit-dev] Long-term Google-URL integration plans

On Thu, Oct 2, 2008 at 6:11 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:

 It sounds to me like you are saying that you would not be willing to
 consider using the current KURL implementation in Chrome, even it
 turns out to be materially better, and it gets exposed with a low-
 level interface that you could use in non-WebCore pieces of Chrome,
 and ends up free of problematic dependencies or license terms.

 Is that a correct interpretation of what you are saying?


We will always be willing to take a better engineering solution over a worse
one.

Given that I don't think KURL _does_ canonicalization right now it's hard
for me to understand what it means to suggest that the current KURL could be
materially better.  And we spent a lot of time on the performance,
footprint, and compatibility of this code, since it's used all over; so I
have confidence in its qualities.  But I think the intent here is to make it
possible to build whatever the right thing is and use it everywhere.  If
there is something low-level that is materially better than what we have to
offer as a starting point (the current low-level code underlying GURL),
whether that already exists or gets created/improved over time, then both
Chromium front-end code and WebCore benefit from using it.

The prospect of WTF types in general tends to make me leery, since using one
can bring in dependencies on others, and we wouldn't want to bring more
dependencies than necessary into the Chromium front-end code; but if this
were confined to using existing lightweight WTF types that didn't depend on
other types, for cases where the current low-level GURL code is already
rolling its own types, then there's probably no loss to anyone by doing that
(and a small gain for embedders already using WTF types).

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

Re: [webkit-dev] High Resolution Timer API proposal(s)

2008-10-02 Thread Ojan Vafai

On Thu, Oct 2, 2008 at 6:20 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:

 On Oct 2, 2008, at 6:14 PM, Ojan Vafai wrote:

 The thing is that often enough the place where you want to modify the
 delay you don't necessarily have access to the callback you would need in
 order to recreate the timer. So, you have to keep track of more stuff in
 JavaScript (e.g. a pointer to the callback). It's not the end of the world,
 but it makes for clunkier uses of the API.

 What do you think of the following?

 interface Timer {
void stop();
void restart(double optional_argument_delayInSeconds);
 }


 Would restart change the time remaining as if that delay had been set
 originally, or would it make the new delay the current time remaining?
 Should it also let you change the repeating status of the timer? (That
 doesn't seem hugely important but this way seems oddly non-orthogonal).

 Perhaps there should be a timeElapsed field (which would give seconds
 actually elapsed since last fire, to the best precision the UA can manage),
 which is useful for both recalculating delays and adjusting for jitter.


The way that makes the most sense to me is that restart would make the new
delay the current time remaining.

Having a timeElapsed field seems like a great addition that doesn't bloat
the API.

I really don't see any good use case for letting you change the repeating
status, so I prefer leaving it out.


 I think I will post it to a standards group soon, probably starting with
 whatwg and possibly moving to webapps if Hixie thinks that is the right way
 to go. We can discuss details further there.


Sounds good.

This is great. It will make a lot of nasty code much cleaner.

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

Re: [webkit-dev] Long-term Google-URL integration plans



On Oct 2, 2008, at 6:26 PM, Peter Kasting wrote:

On Thu, Oct 2, 2008 at 6:11 PM, Maciej Stachowiak [EMAIL PROTECTED]  
wrote:

It sounds to me like you are saying that you would not be willing to
consider using the current KURL implementation in Chrome, even it
turns out to be materially better, and it gets exposed with a low-
level interface that you could use in non-WebCore pieces of Chrome,
and ends up free of problematic dependencies or license terms.

Is that a correct interpretation of what you are saying?

We will always be willing to take a better engineering solution over  
a worse one.


Likewise. If we all agree on that, then there is no problem. It  
sounded to me like Brett either did not agree in this case, or was so  
confident of the superiority of Google-URL that he did not think it  
was even worth considering the alternative.


Given that I don't think KURL _does_ canonicalization right now it's  
hard for me to understand what it means to suggest that the current  
KURL could be materially better.


Extra functionality would certainly count as one way of being  
materially better. Those are the kinds of facts that I think we should  
look at (in addition to comparing behavior, testing perf, etc). But  
for what it's worth, while KURL does not have a canonicalize operation  
that's separate from parsing, it does canonicalize as a side effect  
parsing. It's possible (maybe even likely) that it doesn't apply apply  
all desirable canonicalization rules.


And we spent a lot of time on the performance, footprint, and  
compatibility of this code, since it's used all over; so I have  
confidence in its qualities.


I similarly have some confidence in the qualities of KURL (even  
knowing that there is room for improvement) but not so much that I'd  
be willing to bet on it without comparison testing.


But I think the intent here is to make it possible to build whatever  
the right thing is and use it everywhere.  If there is something low- 
level that is materially better than what we have to offer as a  
starting point (the current low-level code underlying GURL), whether  
that already exists or gets created/improved over time, then both  
Chromium front-end code and WebCore benefit from using it.


Sounds good to me.

The prospect of WTF types in general tends to make me leery, since  
using one can bring in dependencies on others, and we wouldn't want  
to bring more dependencies than necessary into the Chromium front- 
end code; but if this were confined to using existing lightweight  
WTF types that didn't depend on other types, for cases where the  
current low-level GURL code is already rolling its own types, then  
there's probably no loss to anyone by doing that (and a small gain  
for embedders already using WTF types).


Yes, I can see that pulling in an open-ended set of dependencies would  
defeat the purpose of the exercise for you guys. I would not expect  
that to happen.


Regards,
Maciej

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

Re: [webkit-dev] High Resolution Timer API proposal(s)

On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
 Timer startTimer(double delayInSeconds, bool repeating, Function
 callback);

 interface Timer {
 void stop();
 }

One other random idea. What about mixing up the param order for
parallelism with the existing timer APIs:

Timer startTimer(Function callback, double delay, bool repeating);

That would make a call look like this:

var timer = startTimer(function() { ... }, 42, true);

Which feels more familiar, but at the same timer better. Less new
things to remember. Also, I think this argues for the unit to continue
being milliseconds, again, for familiarity.

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

Re: [webkit-dev] High Resolution Timer API proposal(s)

2008-10-02 Thread Alex Iskander

I agree. Repeating, it seems to me, should be an optional argument;  
the callback and time, on the other hand, are completely necessary.

The default value for repeating is probably up for debate. Would  
more web developers use it for repitition, or for single-use? For high  
resolution purposes (the original purpose of the proposed API), it  
seems more likely to be one use only.

Sent from Alex's iPhone

On Oct 2, 2008, at 8:50 PM, Aaron Boodman [EMAIL PROTECTED] wrote:

 On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak [EMAIL PROTECTED]  
 wrote:
 Timer startTimer(double delayInSeconds, bool repeating, Function
 callback);

 interface Timer {
void stop();
 }

 One other random idea. What about mixing up the param order for
 parallelism with the existing timer APIs:

 Timer startTimer(Function callback, double delay, bool repeating);

 That would make a call look like this:

 var timer = startTimer(function() { ... }, 42, true);

 Which feels more familiar, but at the same timer better. Less new
 things to remember. Also, I think this argues for the unit to continue
 being milliseconds, again, for familiarity.

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

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

Re: [webkit-dev] High Resolution Timer API proposal(s)

On Thu, Oct 2, 2008 at 7:08 PM, Alex Iskander [EMAIL PROTECTED] wrote:
 I agree. Repeating, it seems to me, should be an optional argument; the
 callback and time, on the other hand, are completely necessary.

Good point.

 The default value for repeating is probably up for debate. Would more web
 developers use it for repitition, or for single-use? For high resolution
 purposes (the original purpose of the proposed API), it seems more likely to
 be one use only.

I think it usually makes sense to have optional boolean params default
to false, since undefined coerces to false in JS.

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

Re: [webkit-dev] High Resolution Timer API proposal(s)

2008-10-02 Thread Alex Iskander

Good point. And although you could change it to dontRepeat, I don't  
think it would make much sense.

Sent from Alex's iPhone

On Oct 2, 2008, at 9:15 PM, Aaron Boodman [EMAIL PROTECTED] wrote:

 On Thu, Oct 2, 2008 at 7:08 PM, Alex Iskander [EMAIL PROTECTED] wrote:
 I agree. Repeating, it seems to me, should be an optional  
 argument; the
 callback and time, on the other hand, are completely necessary.

 Good point.

 The default value for repeating is probably up for debate. Would  
 more web
 developers use it for repitition, or for single-use? For high  
 resolution
 purposes (the original purpose of the proposed API), it seems more  
 likely to
 be one use only.

 I think it usually makes sense to have optional boolean params default
 to false, since undefined coerces to false in JS.

 - a

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

Re: [webkit-dev] New simplified patch review interface for bugs.webkit.org

2008-10-02 Thread John Sullivan

This is a huge improvement -- thanks Adam!

John

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

Re: [webkit-dev] Proposed Timer API

2008-10-02 Thread Justin Haygood

How about a static:

Timer::startTimer(function(),delayInSeconds) ?

--
From: Cameron McCormack [EMAIL PROTECTED]
Sent: Thursday, October 02, 2008 9:01 PM
To: Maciej Stachowiak [EMAIL PROTECTED]
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Proposed Timer API

 Hi Maciej.

 Cameron McCormack:
  If possible, it would be nice if there could be some degree of
  compatibility between this proposed API and the one in SVG Tiny 1.2:
 
   http://dev.w3.org/SVG/profiles/1.2T/publish/svgudom.html#svg__SVGTimer

 Maciej Stachowiak:
 I considered that, but I don't like the fact that it makes the common
 zero-delay continuation callback case into three lines of code instead
 of one, for what I think is no practical benefit.

 Justin’s proposed API seems to need four lines for that case:

  var t = new Timer();
  t.repeatCount = 1;
  t.addEventListener('timercomplete', function() { … }, false);
  t.start();

 compared with the three for SVG’s timer:

  var t = createTimer(0, -1);
  t.addEventListener('SVGTimer', function() { … }, false);
  t.start();

 Or do you mean compared to a simple function-like API, such as
 setTimeout(), where it can be done in one line?  (Perhaps functions like
 setHighResolution{Interval,Timeout}() would be easiest then.)

 -- 
 Cameron McCormack ≝ http://mcc.id.au/
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] High Resolution Timer API proposal(s)


On Oct 2, 2008, at 6:50 PM, Aaron Boodman wrote:

 On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak [EMAIL PROTECTED]  
 wrote:
 Timer startTimer(double delayInSeconds, bool repeating, Function
 callback);

 interface Timer {
void stop();
 }

 One other random idea. What about mixing up the param order for
 parallelism with the existing timer APIs:

 Timer startTimer(Function callback, double delay, bool repeating);

 That would make a call look like this:

 var timer = startTimer(function() { ... }, 42, true);

 Which feels more familiar, but at the same timer better. Less new
 things to remember. Also, I think this argues for the unit to continue
 being milliseconds, again, for familiarity.

The reason I like the other parameters first is that the function  
parameter could plausibly be quite long. Let's say you are writing a  
big continuation function inline, to communicate work in progress via  
lexically visible variables, and let's say maybe even you nest it:

startTimer(function() {
 while (true) {
 //do very important work
 // do even more important work
 }

 if (important)
 work();

 startTimer(function() {
 // do even more important work

 if (doSomethingLater)
 startTimer(function() {

  // stuff to do later

 }, 42, false);

// even stillmore important stuff

 }, 0, false);

}, 0, false);


That seems pretty oogey to me.

On the other hand, I agree (as stated elsewhere in the thread) that  
constantly mentioning false for non-repeating is lame. I think there  
are three ways to deal with that:

1) Reorder the parameters as you have proposed and make the boolean  
optional (perhaps even make the time optional too, defaulting to 0).

2) Keep the parameters in the order I proposed, but make the first  
ones optional - that's a little weird, but not untenable.

3) Split the method into startTimer and startRepeatingTimer.


I think I will mention some of these possible variations when  
proposing the spec. At Hixie's suggestion I will propose it as a  
standalone spec on [EMAIL PROTECTED], I recommend that those who  
wish to follow the discussion subscribe to that list.


Regards,
Maciej






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

Re: [webkit-dev] High Resolution Timer API proposal(s)

2008-10-02 Thread Cameron McCormack

Maciej Stachowiak:
 I think I will mention some of these possible variations when  
 proposing the spec. At Hixie's suggestion I will propose it as a  
 standalone spec on [EMAIL PROTECTED], I recommend that those who  
 wish to follow the discussion subscribe to that list.

Hixie mentioned at one point that he’d like to see WindowTimers in a
separate spec, I think.  Now that there is the event loop stuff in
HTML 5 I don’t know whether that’s still his opinion, but if it is, will
you include setInterval()/setTimeout() in this Web Apps spec?  That
would be useful for SVG in the future.

Thanks,

Cameron

-- 
Cameron McCormack ≝ http://mcc.id.au/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] High Resolution Timer API proposal(s)


On Oct 2, 2008, at 8:27 PM, Cameron McCormack wrote:

 Maciej Stachowiak:
 I think I will mention some of these possible variations when
 proposing the spec. At Hixie's suggestion I will propose it as a
 standalone spec on [EMAIL PROTECTED], I recommend that those  
 who
 wish to follow the discussion subscribe to that list.

 Hixie mentioned at one point that he’d like to see WindowTimers in a
 separate spec, I think.  Now that there is the event loop stuff in
 HTML 5 I don’t know whether that’s still his opinion, but if it is,  
 will
 you include setInterval()/setTimeout() in this Web Apps spec?  That
 would be useful for SVG in the future.

I think it would be a good idea to include the older existing timer  
APIs, yes.

Regards,
Maciej

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

Re: [webkit-dev] Long-term Google-URL integration plans

On Thu, Oct 2, 2008 at 6:40 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:


 On Oct 2, 2008, at 6:26 PM, Peter Kasting wrote:

 The prospect of WTF types in general tends to make me leery, since using
 one can bring in dependencies on others, and we wouldn't want to bring more
 dependencies than necessary into the Chromium front-end code; but if this
 were confined to using existing lightweight WTF types that didn't depend on
 other types, for cases where the current low-level GURL code is already
 rolling its own types, then there's probably no loss to anyone by doing that
 (and a small gain for embedders already using WTF types).


 Yes, I can see that pulling in an open-ended set of dependencies would
 defeat the purpose of the exercise for you guys. I would not expect that to
 happen.



My main concern is that the code be parameterized (templatized) properly so
that we can use it with the data types that are compatible with Chromium
code (STL) as well as WebKit code (WTF).  I don't think it is desirable to
depend on WTF directly since that would introduce WTF types into elements of
Chromium that are otherwise quite divorced from WebKit (e.g., our network
stack).  This is why I told you that I supported a type neutral core w/
interfaces like KURL and GURL that cater to a particular choice of container
types.  I think if you study the code and our usage of the code in Chromium,
you will see that this is a reasonable requirement.

At this stage, I think it is difficult to know exactly what the proposed
code will look like.  However, IMO the general direction that we arrived at
is good since it is a path that will allow all WebKit-based products
(including Chrome!) to converge on a better solution for URL parsing and
canonicalization.

That said, I am on the same page as Brett.  In the short term, the #ifdef he
proposed is not going to be hard for us to maintain in the interim or
forever if we end up agreeing to disagree about the future of KURL.  We
really do not wish to burden anyone with having to maintain our #ifdefs (or
anything related to our port!), but a few #ifdefs can go a long way to
helping free us to work on more important WebKit issues.  We really abhor
#ifdefs, but sadly they are sometimes the best way.

We can also do a version of what Brett proposes without introducing any
#ifdefs if that would be preferrable.

#include KURLPrivate.h
class KURL {
 public:
  // interface methods
 private:
  KURLPrivate p;
};

If we then put KURLPrivate.h into a subdirectory, it will be easy to change
that out at build time.  Bottom line: we don't want to cause existing WebKit
maintainers any extra headache here.

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

Re: [webkit-dev] setTimeout as browser speed throttle

On Wed, Oct 1, 2008 at 5:26 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:


 On Oct 1, 2008, at 5:03 PM, Darin Fisher wrote:



 On Wed, Oct 1, 2008 at 2:34 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote:


 On Oct 1, 2008, at 1:24 AM, David Hyatt wrote:

 On Oct 1, 2008, at 2:52 AM, Darin Fisher wrote:


 I can appreciate that you aren't interested in revisiting this problem
 after having resolved it finally by adding the clamp.  I believe you when
 you say you had compelling evidence too.



 We are interested in revisiting the problem or we wouldn't be suggesting a
 new high resolution timer API.


 I'm with Hyatt. The reason we are having this thread is precisely to
 revisit the problem.



 Good to hear.  From what you wrote, I thought you were disinterested in
 considering lower clamp values for setTimeout, and that is what I was
 referring to.  (I knew you supported a high-res timer API.)  From what you
 say below, however, I see that you are interested in lowering the clamp
 value.  Sorry for misunderstanding.


 I'm interested in finding out whether there is a value lower than 10ms but
 higher than 1ms that is (a) safe and (b) beneficial for performance on real
 sites. It seems clear to me that 1ms is not safe.

 My impression from your remarks was that you thought 1ms is working fine,
 and that passively waiting to get more feedback from Chrome users was an ok
 way to confirm that it is fine. If that's not what you meant, then my
 apologies for misinterpreting. If it is what you meant, then I continue to
 respectfully disagree on both fronts.


I am indeed interested in passive feedback from users and web developers.
 But I'm also interested in the anonymous, opt-in aggregate data collection
that we can perform ourselves (as Linus mentioned).  The challenge is to
find a way to be confident in selecting a clamp value.  Feedback from users
seems like an important metric but it is not the only metric.






 I don't know how clear I was in the previous email, but basically it can
 take a lot of time before you see problems.  What happens is a site makes a
 change, screws up and puts in an unintentional setTimeout loop, and then
 they pwn the CPU of a browser with no clamp.  They don't discover it because
 every browser has a pretty high clamp.  When we had these issues, they'd
 basically crop up one site at a time every so often.  The good news is that
 usually the sites would fix the problems, but the bad news is it could take
 a while, and angry users would be switching to Firefox.


 That is what I was alluding to when I said it took us 3.5 years to first
 realize we had to add the clamp. The problems come and go, but they are
 consistently a problem, and it can take a while to realize it.


 Yup, I can totally see that happening.  This is why I highlighted our
 architecture, which helps more squarely place blame on misbehaving sites.
  That should help developers and users more easily see who to blame, which
 should help these issues get more visibility and be resolved more quickly.
  I may be wrong, but I'm curious to find out.


 This seems implausible to me. When a site misrenders, it is obvious which
 site is misbehaving, but users still usually blame the browser, not the
 site.


I think that users often only notice high CPU usage after it has been
occurring for a while.  At that point it is frequently not well correlated
to recent browsing activity.  You might have already opened other tabs.
 Maybe it was even a background tab that started acting up.  In a single
process browser, a user just sees the browser process consuming CPU.  In
Chrome, they see a particular tab (or maybe a set of tabs) consuming CPU.
 So they can diagnose the problem and point fingers more easily.

In short, our architecture makes me more willing to take risks with
setTimeout clamping than I would be otherwise.  This is a good thing I think
because we have the opportunity to test this out and get more data without
risking as much.





 Laptops on battery power are not an issue since we wouldn't want to enable
 high-res timers on those systems.  timeBeginPeriod(1) being too costly
 there.


 There's no such thing as timeBeginPeriod on Mac or Linux. And I believe the
 timeBeginPeriod problem is solvable on Windows (there is no need to have it
 on all the time). Overall I think it would be poor form if site behavior
 changed depending on whether I was plugged into a power cable.


Yeah, I realize that this is a Windows only API.  I think we just disagree
here.  In my opinion since setTimeout clamping is so varied across browsers
and even varies in Firefox depending on whether or not a flash animation is
going, the expectation of consistent clamping has to be low.  Or at least it
has to be the case that it doesn't matter much if different browsers have
different clamping values in practice.  So I think there is room to do
interesting things related to different power management states.  Anyways,
I'm just telling you

Re: [webkit-dev] setTimeout as browser speed throttle


On Oct 2, 2008, at 9:39 PM, Darin Fisher wrote:


 I am indeed interested in passive feedback from users and web  
 developers.  But I'm also interested in the anonymous, opt-in  
 aggregate data collection that we can perform ourselves (as Linus  
 mentioned).  The challenge is to find a way to be confident in  
 selecting a clamp value.  Feedback from users seems like an  
 important metric but it is not the only metric.

I think testing on already the known problem sites with different  
clamp values, and hunting for more problem sites in some active way,  
are probably the most valuable additional data gathering that we can do.


 I think that users often only notice high CPU usage after it has  
 been occurring for a while.  At that point it is frequently not well  
 correlated to recent browsing activity.  You might have already  
 opened other tabs.  Maybe it was even a background tab that started  
 acting up.  In a single process browser, a user just sees the  
 browser process consuming CPU.  In Chrome, they see a particular tab  
 (or maybe a set of tabs) consuming CPU.  So they can diagnose the  
 problem and point fingers more easily.

Our experience is that users often do notice what site is  
inadvertantly causing high CPU, because they file bug reports  
mentioning the URL, and pointing out that it doesn't cause the same  
problem in Firefox. Now, it might be that there are even more problems  
where the user does not identify the problem site and does not file a  
bug; I have no way to rule out that possibility.

 In short, our architecture makes me more willing to take risks with  
 setTimeout clamping than I would be otherwise.  This is a good thing  
 I think because we have the opportunity to test this out and get  
 more data without risking as much.

I guess I don't expect it to make a huge difference but if you would  
like to test a value higher than 1ms but less than 10ms in live code  
I'd certainly love to hear the results.


 Laptops on battery power are not an issue since we wouldn't want to  
 enable high-res timers on those systems.  timeBeginPeriod(1) being  
 too costly there.

 There's no such thing as timeBeginPeriod on Mac or Linux. And I  
 believe the timeBeginPeriod problem is solvable on Windows (there is  
 no need to have it on all the time). Overall I think it would be  
 poor form if site behavior changed depending on whether I was  
 plugged into a power cable.

 Yeah, I realize that this is a Windows only API.

The reason that I mention this is that on Mac and Linux systems,  
there's no special power-wasting system call to enable high-res  
timers.

 I think we just disagree here.  In my opinion since setTimeout  
 clamping is so varied across browsers and even varies in Firefox  
 depending on whether or not a flash animation is going, the  
 expectation of consistent clamping has to be low.  Or at least it  
 has to be the case that it doesn't matter much if different browsers  
 have different clamping values in practice.  So I think there is  
 room to do interesting things related to different power management  
 states.  Anyways, I'm just telling you what we are considering doing.

I'm not really talking about developer expectation here so much as the  
possibility that, if indeed a lower clamp is a performance improvement  
for real sites, then said sites would noticeably slow down the moment  
you unplug. As a user I would find that surprising and weird.

 (I don't understand your comment about not having to have it on all  
 the time.  Surely if a page is asking for a fast setTimeout  
 repeatedly, it would be on all the time.)

My understanding is that timeBeinPeriod(1) is currently on all the  
time in Chrome, even when no short-delay timers are currently pending,  
thus leading to constant greater power consumption. But there is no  
need for it to be on when there are not fast timers pending. See  
WebCore/platform/win/SharedTimerWin.cpp. I think that is a technically  
better approach than switching based on power management state.  
Feedback welcome, though, and perhaps you will still come to a  
different conclusion.

Regards,
Maciej

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

Re: [webkit-dev] High Resolution Timer API proposal(s)


On Oct 2, 2008, at 8:19 PM, Maciej Stachowiak wrote:

 I think I will mention some of these possible variations when
 proposing the spec. At Hixie's suggestion I will propose it as a
 standalone spec on [EMAIL PROTECTED], I recommend that those who
 wish to follow the discussion subscribe to that list.

Here it is: 
http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0009.html 
 

Regards,
Maciej

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

Re: [webkit-dev] setTimeout as browser speed throttle