Re: [webkit-dev] review queue crazy idea
We should also publicize/update these existing resources to help patch authors find reviewers for their patches: http://trac.webkit.org/wiki/CodeReview http://trac.webkit.org/wiki/WebKit%20Team I think the most effective approach is when patch authors proactively seek out reviewers. We're all busy, but when I'm asked to review a patch, I make time for it or point the person at another reviewer. Dave -- Sent from my iPhone 4 On Jul 22, 2010, at 12:29 AM, Maciej Stachowiak wrote: > > On Jul 21, 2010, at 3:41 PM, Eric Seidel wrote: > >> Wow. I really like this idea of helping contributors better >> understand what's going wrong. >> >> But, I think that even better would be to build a better front-end for >> reviews. Or a bot which knew how to suggest reviewers (based on >> annotate information from lines changed). > > > I think a better UI for reviews, plus some better attempts at active > notification of potential reviewers, could go a long way. I'm a strong > believer in trying nudges and positive incentives before implementing harsher > policies. > > Regards, > Maciej > > ___ > 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] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?
On Jul 22, 2010, at 2:12 PM, Gustavo Sverzut Barbieri wrote: > Sorry to disturb this already dead thread, but we're (webkit-efl) thinking of > letting applications/browsers register new protocol handlers to provide > contents themselves. A co-worker, Flávio Ceolin, will send more details in > another thread, but do you have any idea on the path to have them generically > in WebCore? WebKit on Mac OS X already supports this and most other ports as well. Adding it to a platform does not require any changes to WebCore. The frame policy functions in FrameLoaderClient are the hook for this sort of thing, specifically dispatchDecidePolicyForNavigationAction. WebKit looks at the URL and decides it’s something an application can handle based on the OS-specific system for handling such things. Then if it does want to handle it, it calls the frame policy function with the action "ignore", which prevents WebCore from doing anything with the link, and then passes the URL on to the other application. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Clients and the Page constructor
I've filed https://bugs.webkit.org/show_bug.cgi?id=42834 to track the addition of a structure to pass pointers to the clients for optional features. Feedback welcome. Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A Parallel Webkit?
I wasn't entirely sure what OP was after of if the reply below
adequately addressed his interests. After looking at the link
provided, I thought I would make a few comments that may or
may not be of much benefit ( for discussion ) but that relate
to observations on a few recent browsers on one series of mobile phones.
> Date: Thu, 22 Jul 2010 22:20:34 +0200
> From: abe...@inf.u-szeged.hu
> To: webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] A Parallel Webkit?
>
> Hi Ying,
>
> you might be looking for WebKit2, wich is a non-blocking API layer for
> WebKit and aims to make WebKit more suitable for multicore systems. It
> supports the split-process model and the thread model as well. The API
> is currently under development for the Mac and Windows ports of WebKit
> (Safari), and the Qt port also tries to keep pace with WebKit2
> development, but currently lags behind the Mac and Win versions a bit.
> There is a test browser called MiniBrowser, you can try it if you are
> interested.
>
> You can find more information about WebKit2 at:
> http://trac.webkit.org/wiki/WebKit2
>
> regards,
> Andras
>
>
> 2010-07-22 17:43 keltezéssel, gao ying írta:
>> Hi,
>>
>> Is WebKit well parallel for fitting in multicore architecture? And any
>> status for the parallel Webkit? The same idea is from
>> http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/
I guess I would just make a few comments about your considerations and our
experience.
A somewhat different strategy than what you are proposing is to offload some
tasks
to a more capable device such as a server- simply tokenizing html or compiling
JS can be a big benefit in phone CPU and bandwidth (aka time and battery life).
Many people rush to parallelism even with only one core or may try to
use many cores and then they compete with each other, often thrashing memory
caches or worse going to VM ( on smaller desktop computers like mine this is a
problem).
You don't need to dig too deeply into the literature to find non monotonic
graphs
of execution time for some task vs number of cores ( more can make things
slower).
I have seen this with transcoding and profiling on phone simulators- parsing
and compiling is a great way to use time and create lots of objects ( and these
in java have lots of overhead and many phones only let you use java but in any
case we know that temp objects are not free in any case and fragment memory).
Another rate limiting step has been the round trip delay to housekeep a
connection
or do a DNS lookup. Here a proxy with persistent connections properly
implemented
is a much bigger issue than optimized rendering or well transcoded web pages
AFAIK.
It may be worth considering making a standard compiled page type rather than
worry about some of these other issues for example and cached compiled pages of
course
greatly reduce problems for everyone.
Its important to remember that most of these things involve tradeoffs and
there are many resources to consider.
So, maybe you can make various arguments (" but with wifi IO doesn't matter "
or " CPU's are only getting faster" or "memory is only getting cheaper" ) and
battle out platittudes to defend a given approach but I wouldn't just point to
one, like parallelism, and assume that will fix everything and indeed it can
make things
worse. Making things smaller in a way you don't need to undo ( say use winzip
to download
and then unzip the html only to compile it etc) is potentially a benefit in any
situation
as long as radio usage requires power.
An immediate concern I would point to in regard to multithreading on desktop
and mobile is the need to keep a responsive UI thread- not sure if webkit has
addressed this fully but I have seen this as a huge problem on my desktop,
mobile,
and my own mobile code that I ( carefully LOL) wrote myself.
>>
>> Thanks,
>> -Ying
>>
>>
>>
>> ___
>> 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
_
Hotmail is redefining busy with tools for the New Busy. Get more from your
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?
Sorry to disturb this already dead thread, but we're (webkit-efl) thinking of letting applications/browsers register new protocol handlers to provide contents themselves. A co-worker, Flávio Ceolin, will send more details in another thread, but do you have any idea on the path to have them generically in WebCore? IMO, the logics would require the network backend to delegate to WebCoreSupport the unsupported KURL before failing, that could return some instance to handle the job. This class/instance to handle the job is not abstracted right now, but could be done in a way that we could use it in soup/curl (webkit-efl supported backends) and also in qt. For instance, Qt always delegate access using QNetworkAccessManager and can do what we said, but it is port-specific. As we have 2 network backends (we will likely remain with curl later), having a generic alternative is better, but we could just reuse our code in both backends. Any help is appreciated. Regards! On Thu, Jul 8, 2010 at 3:27 PM, Dmitry Titov wrote: > Thanks to all, > the bug is here: https://bugs.webkit.org/show_bug.cgi?id=41878 > I've added link to tracking Chromium bug as well. > Dmitry > > > On Wed, Jul 7, 2010 at 7:59 PM, Jeremy Orlow wrote: >> >> That would be the standard thing to do. >> The sooner someone gets started on the feature, the easier it'll be to >> revert the patch that removes the code. :-) >> J >> >> On Thu, Jul 8, 2010 at 10:55 AM, David Levin wrote: >>> >>> >>> On Wed, Jul 7, 2010 at 5:24 PM, Peter Kasting >>> wrote: On Wed, Jul 7, 2010 at 5:00 PM, Dmitry Titov wrote: > > I'd lean to the removal, unless there is a port that has work ongoing > or planned soon for those implementations. > Does anybody vote for #ifdefs? I vote against removal if only because Chromium has really wanted these badly for a long time and simply hasn't been able to find someone to implement them. Perhaps I could make it worth your while to implement rather than remove the stubs? :) >>> >>> Even if someone to implement them for chromium, it doesn't seem to fix >>> the overall problem. Dmitry indicated that the presences of these is >>> breaking feature detection in browsers using WebKit (-- which is something >>> being heard from web developers). >>> A simple solution is to remove them. Later, any port (including chromium) >>> who gets someone to work on them could re-add these methods back properly >>> under ifdef's. >>> dave >>> ___ >>> 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 > > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A Parallel Webkit?
Hi Ying, you might be looking for WebKit2, wich is a non-blocking API layer for WebKit and aims to make WebKit more suitable for multicore systems. It supports the split-process model and the thread model as well. The API is currently under development for the Mac and Windows ports of WebKit (Safari), and the Qt port also tries to keep pace with WebKit2 development, but currently lags behind the Mac and Win versions a bit. There is a test browser called MiniBrowser, you can try it if you are interested. You can find more information about WebKit2 at: http://trac.webkit.org/wiki/WebKit2 regards, Andras 2010-07-22 17:43 keltezéssel, gao ying írta: Hi, Is WebKit well parallel for fitting in multicore architecture? And any status for the parallel Webkit? The same idea is from http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/ Thanks, -Ying ___ 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] review queue crazy idea
On Wed, Jul 21, 2010 at 4:47 PM, Eric Seidel wrote: > Patches sit in the queue for numerous reasons. Some of us used to > scan the queue every day. But I've stopped doing that. Now I scan it > more like once a week or two. > > There is no good way to find "which patches might I have a chance of > reviewing", so you end up spending 30 minutes just to find a patch you > could actually review. > Maybe one way you could do this would be to look at bugs in the review queue that have been modified in the past day: https://bugs.webkit.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&chfieldfrom=1d&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%3F . ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] A Parallel Webkit?
Hi, Is WebKit well parallel for fitting in multicore architecture? And any status for the parallel Webkit? The same idea is from http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/ Thanks, -Ying ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Clients and the Page constructor
On Wed, Jul 21, 2010 at 8:57 PM, Steve Block wrote: > > Another argument for the setter is that it makes it easier to inject a > mock for testing in response to a LayoutTestController method call, by > simply calling the setter again to replace the real client with a mock > client. Personally, however, I think that this is somewhat abusing the > idea of setting a client. If the real implementation needs to be > switched for a mock at runtime in DRT, this should probably be handled > by the client itself - so the same client is used throughout the > lifetime of the Page. > Furthermore, none of the cases that I am familiar with (Geolocation, Device Orientation, speech) require to start in DRT with a real client implementation and then, later, switch to a mock in response to some DRT method call. They all can quite happily pass the mock client pointer in the Page ctor. So the mock injection argument you mention above is for a problem that does not exist in reality. Thanks, Andrei ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] review queue crazy idea
On Thu, Jul 22, 2010 at 8:29 AM, Maciej Stachowiak wrote: > > > I think a better UI for reviews, plus some better attempts at active > notification of potential reviewers, could go a long way. I'm a strong > believer in trying nudges and positive incentives before implementing harsher > policies. > Maybe we could have the system try to contact reviewers who have expressed interest/ability in review patches for certain areas (or components)? For example, if someone registered as being a reviewer for MathML patches, the system could e-mail all the registered reviewers. If the set of reviewers is too large, the system could pick a random subset to e-mail. I have certainly had a consistent set of individuals who have been kind enough to review my patches. On occasion, I've contacted individuals to ask directly for a review when a patch has been there for awhile. I've gotten comfortable enough with the process to do this. Newer contributors or those contributing outside their normal areas might not feel so comfortable and so having the system do this would be very good for keeping things moving forward. -- --Alex Milowski "The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered." Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] review queue crazy idea
On Jul 21, 2010, at 3:41 PM, Eric Seidel wrote: > Wow. I really like this idea of helping contributors better > understand what's going wrong. > > But, I think that even better would be to build a better front-end for > reviews. Or a bot which knew how to suggest reviewers (based on > annotate information from lines changed). I think a better UI for reviews, plus some better attempts at active notification of potential reviewers, could go a long way. I'm a strong believer in trying nudges and positive incentives before implementing harsher policies. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
