On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> 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 architect
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.
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 ha
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
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
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
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
> dependencie
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 foll
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 a
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
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 abo
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 AP
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
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
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 m
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 purpo
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 ti
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 bette
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
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 inter
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 p
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
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
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
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 impl
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 fract
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. Be
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 d
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,
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, O
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 ove
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]>
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 develo
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
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
> > overengine
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 backgroun
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 b
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:
>
> htt
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
p
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 con
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 merg
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::s
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 r
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
> 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?
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
num
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
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 peopl
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
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 poin
> 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 dif
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 n
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 GUR
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.co
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
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 implementa
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 c
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.
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
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 ope
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
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
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 Potent
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
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
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 lik
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)
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 Potent
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:
> >
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 awa
On Oct 2, 2008, at 6:01 AM, Linus Upson wrote:
>> My impression from your remarks was that you thought 1ms is working
>> fine
>
> 1ms is definitely not working fine for me. I've started reading the
> Washington Post since NYT makes my fan whir.
As another drastic anecdotal step, I've turned of
Oct 2, 2008, в 12:53 PM, Dmitry Titov написал(а):
> On a separate note, it almost feels that just adding
> invokeAsSoonAsPossible(handler) that is equivalent to unclamped
> setTimeout(..., 0) could be all that's needed.
I think that this can be done today with window.postMessage. One can
p
Since our systems are not real-time, saying 'hi-res timer' and 'event
dispatching' together may need some clarification.
Lets say we set delay=0.001 - but not every system can guarantee that the
timer event will fire at precise 1 ms interval. So it can "skip a bit" or
fire at longer delay, then con
73 matches
Mail list logo
