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

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

2008-10-02 Thread Mike Hommey

On Thu, Oct 02, 2008 at 11:06:19AM -0700, Maciej Stachowiak wrote:
>
> 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.

Sure, but what would be interesting is the comparison with the total
size, which isn't 100% pointers.

Mike
___
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 2, 2008, at 11:14 AM, Mike Hommey wrote:

> On Thu, Oct 02, 2008 at 11:06:19AM -0700, Maciej Stachowiak wrote:
>>
>> 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.
>
> Sure, but what would be interesting is the comparison with the total
> size, which isn't 100% pointers.

Yes, the total cost would likely less than double. The DOM is mostly  
pointers, the render tree is maybe half pointers, and image data would  
not change size at all. So proportionately, it would be more expensive  
on 64-bit.

Regards,
Maciej

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

[webkit-dev] Webkit and Windows.Forms issue

2008-10-02 Thread John Penman (jopenman)

Hi all,

  I have been trying over the last few weeks with little success to
integrate Webkit into a VC2005 project that uses Windows.Forms for its
GUI.  I have successfully built the WinLauncher application that comes
with the WebKit package, but that project relies heavily on its
integration with the WebKit Solution.  After some work I was able to
build a version of WinLauncher outside the WebKit solution, but cannot
find a solution that will allow me to integrate into a Windows.Forms .h
file.  Since the VC2005 GUI designer creates it forms in .h files.

 

I am writing my app in C++/CLI mode (not C#).  Brief description:

 

I am trying to display the WebView in a Panel (contentPanel) on my Form:

 

IntPtr ptrHwnd = contentPanel->Handle;

HWND newHwnd =
(HWND)ptrHwnd.ToPointer();



pin_ptr p = &gWebView;

HRESULT hr =
CoCreateInstance(CLSID_WebView, 0, CLSCTX_ALL, IID_IWebView, (void**)p);

if (FAILED(hr))

goto exit;

 

gWebHost = new CPortalBrowserWebHost();

gWebHost->AddRef();

hr =
gWebView->setFrameLoadDelegate(gWebHost);

if (FAILED(hr))

goto exit;

 

hr =
gWebView->setHostWindow((OLE_HANDLE) ptrHwnd.ToPointer());

if (FAILED(hr))

goto exit;

 

RECT clientRect;

GetClientRect(newHwnd, &clientRect);

hr = gWebView->initWithFrame(clientRect,
0, 0);

if (FAILED(hr))

goto exit;

 

It fails on the hr = gWebView->initWithFrame(clientRect, 0, 0); with an
error code of (-2147024882).

 

If anyone can help with this issue I would greatly appreciate it!

 

___
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

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

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:

> 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

___
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:
>
>> 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

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

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 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

___
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

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 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.

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 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

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

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

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.

This code would have no WebCore, WTF, or STL types in it. 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.

Brett
___
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

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: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

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)

On Thu, Oct 2, 2008 at 5:43 PM, Darin Fisher <[EMAIL PROTECTED]> wrote:

> 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?
>

Yes. :)

Ojan
___
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] Proposed Timer API


On Oct 2, 2008, at 6:01 PM, Cameron McCormack wrote:

> 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();

See my proposal on another thread, which makes this:

startTimer(0, false, function() { ... });

> 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.)

Yeah, my proposal is something like that, but just one function and  
without bothering to mention "HighResolution" in the name.

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:
>
> 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)?
>

I guess a better name would be restart? I don't see the need for there to be
a stop and a pause. I realize they are subtley different, but not enough
that it's worth a more complicated API. In short, I would expect
restart/resume to start the timer over, as if a new timer were created.

> 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.
>

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);
}

Ojan
___
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)

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: 
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] Proposed Timer API

2008-10-02 Thread Cameron McCormack

Justin Haygood:
> How about a static:
>
> Timer::startTimer(function(),delayInSeconds) ?

Browser JS APIs tend not to use static methods, i.e. functions on
constructor objects.  Whether that’s because the IDL being used doesn’t
support such a construct I’m not sure.  So usually those functions end
up on the Window object, at which point this suggestion seems to be
quite similar to Maciej’s proposal.

-- 
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)

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 th

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: 


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

On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:

>
> On Oct 2, 2008, at 9:39 PM, Darin Fisher wrote:
>
>  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.
>

When we have that data, we'll share it.  I'm not sure when that will happen.



>  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.
>


My laptop slows down considerably when I unplug it because of power saving
settings.  I don't find that too unusual.




>  (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.
>


I think that is a good idea too, but it doesn't help when a fast setInterval
is active.

-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 Oct 2, 2008, at 10:09 PM, Darin Fisher wrote:

On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:


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

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.


When we have that data, we'll share it.  I'm not sure when that will  
happen.


Are you planning to test a specific alternate interval?

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.



My laptop slows down considerably when I unplug it because of power  
saving settings.  I don't find that too unusual.


Mine doesn't. Instead it slews the CPU clockspeed based on workload  
and shuts down components (including the CPU) whenver possible. Get a  
Mac. :-) In all seriousness, I see your point for Windows machines.  
User expectations for the unplugged state may be lower.


(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.


I think that is a good idea too, but it doesn't help when a fast  
setInterval is active.


That is true. With the webkit.org version of SharedTimerWin, though,  
you can at least close the problematic tab when you hear your fan spin  
up and stop suffering any power drain. It may be that running slower  
is a better option.


Cheers,
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