Re: [webkit-dev] Non-Scaling Stroke feature (SVGT 1.2)
Hi Dirk, I wasn't aware of another bug, sorry. Actually on the patch that I have already attached to that bug, it seems to work in the few test cases I've been able to find (my own and a couple from the SVGT 1.2 test suite). While stroking, I transform the path with the CTM of the context and un-transform the context (with its inverse matrix). Then I undo that after stroking. The only thing that may be a problem is the dirty rectangle that is created by paths with non-scaled-strokes. I need to look at that after generating some tests. Regards, Jeff On Tue, Nov 17, 2009 at 12:33 AM, Dirk Schulze k...@webkit.org wrote: Hi, I thougt that we already had a bug about this. It is a good idea to support this feature in general. Even if our support for SVG 1.1 is not perfect, we should think about some features of SVG 1.2 like media support and also non scaling strokes. But implementing non scaling strokes is not that easy. On SVG we transform the context multiple times (translate, scale, skew) and stroke the path at the end. We may think about transforming the path instead of the context but there might be more problems on doing that. -Dirk Am Montag, den 16.11.2009, 16:23 -0600 schrieb Jeff Schiller: Hello, I am interested in having broader support for non-scaling stroke on SVG shapes. This is a SVGT 1.2 feature: http://www.w3.org/TR/SVGTiny12/painting.html#NonScalingStroke This adds a CSS property and attribute: vector-effect. This property can have three values: none (default), inherit, or non-scaling-stroke. When non-scaling-stroke, the stroke (outline) of a shape would maintain its specified width regardless of the transforms applied to the shape. This is very useful when importing foreign SVG into new documents and in GIS/mapping scenarios (for instance, zooming in on a map would not fatten the driving directions path). I realize that WebKit has been generally not interested in SVGT 1.2, but I feel it makes sense to cherry-pick certain features that really do improve SVG on the web. Non-scaling stroke is one of these features. FWIW, Opera has implemented this feature since version 9.5. I have opened a bug and supplied a patch that gets this off the ground in WebKit: https://bugs.webkit.org/show_bug.cgi?id=31438 I only need to figure out how to add some tests (need to understand how pixel tests work in WebKit). Darin Adler requested that I bring this up on this list for discussion. Thanks, Jeff Schiller ___ 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] On the greeness of the GTK+ bot
Hello, for us too, as many of you poited out before me, the main issue is not build breakage while maintaining the QtWebKit buildbot - because these are most of the time trivial fixes - but tracking down the previously passing but after-the-night failing tests. Because of the timezone differences most of the work on the Mac port is done when we here in Europe are in our sleeping-quarters, and a green bot will most certainly be red in the morning and a non-green bot gets out of sight very quickly. However, I find the idea of the try-bots great, because this takes the right direction to a future where try-bots also test the layout tests. We are monitoring changes and their effect on our buildbot and tracking down incremental failures and flakey tests which cause false alarm and disrupt the trustiness of our bot. Another huge problem is, as Dimitri pointed out too, that in most cases we miss a certain DRT feature to run a test correctly. If we spend more effort improving (and btw fixing) DRT and the test infrastructure than improving and fixing the port itself then there might be a problem with the layout-testing approach on multiple ports. BR: Andras (bbandix) Dimitri Glazkov írta: On Mon, Nov 16, 2009 at 5:56 AM, Xan Lopez x...@gnome.org wrote: On Mon, Nov 16, 2009 at 3:33 PM, Gustavo Noronha Silva g...@gnome.org wrote: On Mon, 2009-11-16 at 05:24 -0800, Adam Barth wrote: Eric and I are working on a bot that might help this situation. Essentially, the bot will try out patches on Qt and GTK and add a comment to the bug if the patch regresses the build. Our plan is to start with compiling, but we'd eventually like to run the tests as well. That sounds like an awesome idea. Thanks for working on it. Build breakages themselves have become less of an issue for us in recent times - people are definitely more aware of our bots, and are acting on fixing them when they break. I think such an automated approach to running the build, and tests for upcoming patches will surely help with giving this a second step forward. This is nice to see, but as Gustavo says build breakage is not too much an issue at the moment for us: the build does not break very often, and when it does people usually take the time to figure out what happened and either do fix it themselves or poke us about it. That being said, this could be improved in any number of ways and I'm happy to see it getting ever better. What is effectively a black hole with respect to our time is the tests breakage, though. We get new tests failing very regularly (either through new tests or through new code making old tests fail), and once the bots are red people tend to pay even less attention to them, so they spiral out of control in a positive feedback loop until we have tests failing in the double digits in a matter of days (or hours!). Of course in an ideal world we'd have a team big enough to always have at least one person looking at this and fixing the problems the moment they arise, but unfortunately this is not the case. This is a huge issue with the Chromium port as well. We spend quite a bit of effort tracking down failing tests, only to discover that the failure is due to one-port baselines or new functionality added to DRT. I wonder if the approach we have today in regards to tests is not sustainable with multiple vibrant ports, each spending way to much time catching up. :DG ___ 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] Staging WebSocket protocol deployment
On Mon, Nov 16, 2009 at 5:45 PM, Alexey Proskuryakov a...@webkit.org wrote: 15.11.2009, в 17:18, Yuzo Fujishima написал: Reason 1: It connotes that the feature is experimental. That means there will be less developers seriously use that feature. Without serious use, we'll have less serious feedbacks from the real world. If the Web Socket has serious flaws, we should rather know them sooner than later. I'd say only serious uses can help us find the flaws faster. It doesn't seem that wide use is possible before the protocol evolves into something that works with all proxies - or before a heavyweight service forces network administrators to update their proxies for compatibility with the existing protocol. Frankly, I think that the former is more likely. The only case that is likely to work on Internet reliably right now is running over SSL, which negates some of the protocol's strengths - it will no longer be as efficient as it's meant to be. In order to enable port sharing, this also requires one to serve documents over https, which is an additional cost. You're right that WebSocket users will need to use SSL to get around proxy issues, but I don't think it's actually that big of a deal. I know of several sites looking at using them; all are planning on using SSL, and I'm not aware of any being particularly concerned about this. As for the proxy issues themselves: they're not going to go away any time soon. And the longer we label this protocol as experimental, the longer it's going to take for things to move forward. Reason 2: What should other browser vendors do? Should they use chrome-ws, firefox-ws, ie-ws, opera-ws, ..., etc? I believe at least developers will not happy with that. If the vendors need to reach the consensus on the common experimental name, say prelim-ws, then why not just use ws instead? In practice, this means half a dozen lines of browser detection code - which does not matter when deploying a technology of this magnitude, as already mentioned in this thread. That's not the matter. The matter is what this signals to people considering using WebSockets. Each UA having their own code typically signals that things are non-standard, which is not true in this case. It seems that a common argument against using a name other than ws is that a scheme is just an opaque identifier, so it doesn't matter which name to use, so we can just change the name later, if necessary. I don't think that this is a strong argument - if the name doesn't matter in the long run (which I wouldn't agree with, but anyway), why sweat about what the name is during experimental rollout of the feature? This argument works both for and against. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Error handling support in DRT.
It was agreed on IRC that having DRTs able to handle error pages in not a bad thing, but good since it brings DRT closer to a real browsers behavior. Hence, I moved on here and implemented it for QT's DRT (see https://bugs.webkit.org/show_bug.cgi?id=31509#c0). Currently the single test depending on it is fast/history/back-forward-reset-after-error-handling.html (see https://bugs.webkit.org/show_bug.cgi?id=30573), which is in gtk, win and mac 'Skipped' for now. Also, I've filed follow up bugs for each of these DRT to track down the implementation of such feature for their DRTs: * MAC - https://bugs.webkit.org/show_bug.cgi?id=31555 * GTK - https://bugs.webkit.org/show_bug.cgi?id=31556 * WIN - https://bugs.webkit.org/show_bug.cgi?id=31557 Regards -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A bot-filled future?
On Mon, 2009-11-16 at 18:48 -0800, Geoffrey Garen wrote: I understand why you want to start with a Mac bot, and I applaud starting small. However, bear in mind that lots of WebKit contributors work primarily on the Mac, so they probably won't get any use out of a Mac try bot, and you probably won't get any feedback from them until the try bot expands to cover other platforms. I believe the idea is in fact to start with a GTK+/Qt on Linux bot (since it should be simpler to setup). See you, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebScripting protocol: valueForUndefinedKey: never gets called
Hi everybody, I am in the process of writing some code in ObjC, which would allow me to make calls from Javascript to C++ objects implementing a simple reflection interface (it basically allows you to associated indices with names, and perform operations such as getting/setting/calling on these indices). In order to do this, I created a simple ObjC wrapper object around the C++ interface, which implements the WebScripting protocol. However, since this wrapper object does not have any member variables (they are all hidden behind the C++ interface), I cannot expose these to Javascript directly. Instead, I've tried to make them available using KVC, specifically by using the methods valueForUndefinedKey: and setValue:forUndefinedKey:. For isKeyExcludedFromWebScript: and isSelectorExcludedFromWebScript: I simply always return YES. Setting properties like this seems to work fine. The method get called, and I simply forward it to the reflection interface. Getting properties, on the other hand, does not seem to work: valueForUndefinedKey: simply does not get called. At all. I found an entry on the Apple mailing lists of somebody seemingly having the same problem as me. Unfortunately, there was no answer: http://lists.apple.com/archives/webkitsdk-dev/2008/Oct/msg00021.html Am I overlooking something? Are there any other methods I need to override in order for this to work? Or is it simply a bug in WebKit, since this approach to exposing properties seems to be non-standard, at least. Any feedback on this issue would be very much appreciated! :-) Cheers, Eddy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A bot-filled future?
I believe the idea is in fact to start with a GTK+/Qt on Linux bot (since it should be simpler to setup). Neat. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebScripting protocol: valueForUndefinedKey: never gets called
Hi Eddy. This seems like a bug to me. Would you be willing to file it at bugs.webkit.org? I have a guess at a possible work-around. In the class where you've implemented valueForUndefinedKey:, try also implementing invokeUndefinedMethodFromWebScript:withArguments:. Thanks, Geoff On Nov 17, 2009, at 7:37 AM, Eddy Bruël wrote: Hi everybody, I am in the process of writing some code in ObjC, which would allow me to make calls from Javascript to C++ objects implementing a simple reflection interface (it basically allows you to associated indices with names, and perform operations such as getting/setting/calling on these indices). In order to do this, I created a simple ObjC wrapper object around the C++ interface, which implements the WebScripting protocol. However, since this wrapper object does not have any member variables (they are all hidden behind the C++ interface), I cannot expose these to Javascript directly. Instead, I've tried to make them available using KVC, specifically by using the methods valueForUndefinedKey: and setValue:forUndefinedKey:. For isKeyExcludedFromWebScript: and isSelectorExcludedFromWebScript: I simply always return YES. Setting properties like this seems to work fine. The method get called, and I simply forward it to the reflection interface. Getting properties, on the other hand, does not seem to work: valueForUndefinedKey: simply does not get called. At all. I found an entry on the Apple mailing lists of somebody seemingly having the same problem as me. Unfortunately, there was no answer: http://lists.apple.com/archives/webkitsdk-dev/2008/Oct/msg00021.html Am I overlooking something? Are there any other methods I need to override in order for this to work? Or is it simply a bug in WebKit, since this approach to exposing properties seems to be non-standard, at least. Any feedback on this issue would be very much appreciated! :-) Cheers, Eddy ___ 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] Staging WebSocket protocol deployment
On Nov 15, 2009, at 5:18 PM, Yuzo Fujishima wrote: Hi, I'm against prefixing with webkit- because of the following reasons. Reason 1: It connotes that the feature is experimental. That means there will be less developers seriously use that feature. Without serious use, we'll have less serious feedbacks from the real world. If the Web Socket has serious flaws, we should rather know them sooner than later. I'd say only serious uses can help us find the flaws faster. I think this captures the root of the disagreement. Personally, I would like to do something to send the message that WebSocket is still somewhat experimental. It's true that the spec has been in development for a long time. But we are only now seeing the first client-side and server-side implementations. A number of issues were discovered in that process, and I'd personally like to see some more experimental implementations before we lose the ability to make incompatible changes. See below for some specific suggestions. Reason 2: What should other browser vendors do? Should they use chrome-ws, firefox-ws, ie-ws, opera-ws, ..., etc? I believe at least developers will not happy with that. If the vendors need to reach the consensus on the common experimental name, say prelim-ws, then why not just use ws instead? Historically, we haven't had a problem with WebKit-prefixed features - it seems that other browser vendors implement under their own prefix and content adapts to deal. Anyway, getting back to the suggestions... I think it's reasonable at this point to indicate that the WebSocket protocol is somewhat experimental (probably more so than the API). I will recommend doing something along those lines for the next release of Safari. If we can get rough consensus within the WebKit community that we should label the protocol experimental, and how we should do so, then we can just make the change in WebKit and vendor releases will follow along. Here is an extended list of ideas (ones that I think are practically doable): 1) Change the URI schemes to webkit-ws and webkit-wss - the vendor prefix strategy. 2) Change the URI schemes to x-ws and x-wss - a vendor-independent experimental prefix. 3) Don't change the URI schemes at all, but communicate in some public way that the protocol is not completely locked down yet, and we are largely looking for early adopter feedback. We could do this in the form of a WebKit blog post, for example. And we could reinforce that in developer documentation for WebKit-based products. 4) Support both unprefixed and prefixed URI schemes, and in addition publicize that we will maintain compatibility for the prefixed URI scheme but the unprefixed version may have to change (combo of 3 and either 1 or 2). 5) Make the feature runtime switchable (using some semi-hidden UI) and off by default. I'd like to hear opinions on which of these is best. I'd also like to hear if anyone feels that we should send the message that the WebSocket Protocol is production quality and we promise full compatibility going forward. Does anyone truly feel this way? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Making browsers faster: Resource Packages
Good people of Webkit! We'd all like for the web to be faster, and therefore I'd love your feedback on my proposal — it would be great to see support for this in additional browsers, not just Firefox: http://limi.net/articles/resource-packages/ Summary: What if there was a backwards compatible way to transfer all of the resources that are used on every single page in your site — CSS, JS, images, anything else — in a single HTTP request at the start of the first visit to the page? This is what Resource Package support in browsers will let you do. Looking forward to hear your thoughts on this. Thanks! -- Alexander Limi · Firefox User Experience · http://limi.net ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making browsers faster: Resource Packages
I have many of the same concerns mentioned here: http://ajaxian.com/archives/resource-packages-making-a-faster-web-via-packaging dave (hy...@apple.com) On Nov 17, 2009, at 4:19 PM, Alexander Limi wrote: Good people of Webkit! We'd all like for the web to be faster, and therefore I'd love your feedback on my proposal — it would be great to see support for this in additional browsers, not just Firefox: http://limi.net/articles/resource-packages/ Summary: What if there was a backwards compatible way to transfer all of the resources that are used on every single page in your site — CSS, JS, images, anything else — in a single HTTP request at the start of the first visit to the page? This is what Resource Package support in browsers will let you do. Looking forward to hear your thoughts on this. Thanks! -- Alexander Limi · Firefox User Experience · http://limi.net ___ 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] Making browsers faster: Resource Packages
Could you be more specific? Most of the comments seem to be a result of people not actually reading the spec. As for the comments in the article itself: - You still do parallel downloads, and you can have multiple resource packages. - The zip can have expiry headers, and can be invalidated using ETags. If you can pull out the specific questions, I'm happy to answer them. -- Alexander Limi · Firefox User Experience · http://limi.net On Tue, Nov 17, 2009 at 2:30 PM, David Hyatt hy...@apple.com wrote: I have many of the same concerns mentioned here: http://ajaxian.com/archives/resource-packages-making-a-faster-web-via-packaging dave (hy...@apple.com) On Nov 17, 2009, at 4:19 PM, Alexander Limi wrote: Good people of Webkit! We'd all like for the web to be faster, and therefore I'd love your feedback on my proposal — it would be great to see support for this in additional browsers, not just Firefox: http://limi.net/articles/resource-packages/ Summary: What if there was a backwards compatible way to transfer all of the resources that are used on every single page in your site — CSS, JS, images, anything else — in a single HTTP request at the start of the first visit to the page? This is what Resource Package support in browsers will let you do. Looking forward to hear your thoughts on this. Thanks! -- Alexander Limi · Firefox User Experience · http://limi.net ___ 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] Making browsers faster: Resource Packages
On Tue, Nov 17, 2009 at 2:19 PM, Alexander Limi l...@mozilla.com wrote: We'd all like for the web to be faster, and therefore I'd love your feedback on my proposal I have read the whole document, but I read it quickly, so please do point out places where I've overlooked an obvious response. Reduced parallelism is a big concern of mine. Lots of sites make heavy use of resource sharding across many hostnames to take advantage of multiple connections, which this defeats. You say in this thread that you still do parallel downloads, but it seems to me that you either download this zip in parallel with anything not in the zip (meaning you run out of parallelism faster the more the author makes use of this technique), or else you potentially download in parallel multiple copies of the same resource (one in the zip, one outside), neither of which is good. I am concerned about the instruction to prefer the packaged resources to any separate resources. This seems to increase the maintenance burden since you can never incrementally override the contents of a package, but always have to repackage. One of your stated goals is to avoid downloading resources you already have, but even with manifests, I see no way to do this, since the client can't actually tell the server only send items x, y, and z. If an author has resources only used on some pages, then he can either make multiple packages (more maintenance burden and exacerbates problem above), or include everything in one package (may result in downloading excessive resources for pages where clients don't need them). You note that SPDY has to be implemented by both UAs and web servers, but conversely this proposal needs to be implemented by UAs and _authors_. I would rather burden the guys writing Apache than the guys making webpages, and I think if a technique is extremely useful, it's easier to get support into Apache than into, say, 50% of the webpages out there. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making browsers faster: Resource Packages
On Tue, Nov 17, 2009 at 2:19 PM, Alexander Limi l...@mozilla.com wrote: Good people of Webkit! We'd all like for the web to be faster, and therefore I'd love your feedback on my proposal — it would be great to see support for this in additional browsers, not just Firefox: http://limi.net/articles/resource-packages/ Summary: What if there was a backwards compatible way to transfer all of the resources that are used on every single page in your site — CSS, JS, images, anything else — in a single HTTP request at the start of the first visit to the page? This is what Resource Package support in browsers will let you do. Looking forward to hear your thoughts on this. It seems like a browser will have to essentially stop rendering until it has finished downloading the entire .zip and examined it. This will most likely slow down the time taken to render parts of the page as they arrive. From the blog post: A given browser will probably block downloading any resources until the lists of files that are available in resource packages have been accounted for — or there may be a way to do opportunistic requests or similar, we leave this up to the browser vendor unless there’s a compelling reason to specify how this should work. This also means that a browser would have to stop tokenizing the HTML when it hits the next script src= tag, since it would be unable to know if the javascript was in the bundled zip or not. This seems to go against the idea that as much of the page be rendered as fast as possible. - James Thanks! -- Alexander Limi · Firefox User Experience · http://limi.net ___ 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] Making browsers faster: Resource Packages
On Tue, Nov 17, 2009 at 3:00 PM, James Robinson jam...@google.com wrote: It seems like a browser will have to essentially stop rendering until it has finished downloading the entire .zip and examined it. I think mitigating this is why there are optional manifests. I agree that if there's no manifest, this is really, really painful. I think manifests should be made mandatory. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making browsers faster: Resource Packages
On Nov 17, 2009, at 3:02 PM, Peter Kasting wrote: On Tue, Nov 17, 2009 at 3:00 PM, James Robinson jam...@google.com wrote: It seems like a browser will have to essentially stop rendering until it has finished downloading the entire .zip and examined it. I think mitigating this is why there are optional manifests. I agree that if there's no manifest, this is really, really painful. I think manifests should be made mandatory. If you require a manifest, why not pick an archive format where there's a TOC which is guaranteed to be at the head of the file, which the browser can parse without having to wait for the entire file to download? In my not very extensive reading of pages on the zip format, it appears that the Central Directory is always at the end of the file, which is not very friendly to progressive download of these files. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making browsers faster: Resource Packages
On Tue, Nov 17, 2009 at 3:02 PM, Peter Kasting pkast...@google.com wrote: On Tue, Nov 17, 2009 at 3:00 PM, James Robinson jam...@google.com wrote: It seems like a browser will have to essentially stop rendering until it has finished downloading the entire .zip and examined it. I think mitigating this is why there are optional manifests. I agree that if there's no manifest, this is really, really painful. I think manifests should be made mandatory. PK Do you mean external manifests? Either way, the browser cannot start a download for any external resource until it downloads and parses out the manifest.txt for every resource bundle seen in the page so far. Whether it is pulling the manifest out of a .zip file or as a .txt by itself doesn't matter much, it's still an extra HTTP round-trip before any content can be downloaded (including content that is not bundled at all). - James ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Nov 15, 2009, at 3:19 PM, Adam Barth wrote: On Fri, Nov 13, 2009 at 6:01 PM, Adam Barth aba...@webkit.org wrote: Does the IETF WG have a timeline? My understanding is that IETF WG take at least a year to do anything. Here's the timeline for the HyBi WG: http://trac.tools.ietf.org/bof/trac/wiki/HyBi Goals and Milestones: - Mar-2010: WGLC on the Design Space characterization (Informational) May-2010: WGLC on Requirements document on Short term solution Jul-2010: WGLC on Requirements document on Long term solution Nov-2010: Requirements to IESG Mar-2011: WGLC on Short term solution improvements Nov-2011: WGLC on Long term solution protocol I read this as one year for requirements and another year for a protocol assuming the WG stays on schedule. With regards to timeline: I don't think it is sensible to wait for the IETF to get through the full process all the way to an RFC, particularly if that process takes multiple years. After all, we don't do that for features of HTML5 itself. I think it would be reasonable to give WebSocket 6 months or so in some experimental form, and then declare it ready for prime time if no nasty surprises come up, even if the IETF is still wrapped in beaurocracy. I see also that Mozilla is embarking on a WebSocket implementation. Given these considerations, I am leaning towards option (3) from my recent email, which is to use the regular URI schemes and issue a public warning, or option (4) (support both prefixed and unprefixed). Further opinions welcome. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making browsers faster: Resource Packages
On Tue, Nov 17, 2009 at 3:14 PM, James Robinson jam...@google.com wrote: On Tue, Nov 17, 2009 at 3:02 PM, Peter Kasting pkast...@google.com wrote: On Tue, Nov 17, 2009 at 3:00 PM, James Robinson jam...@google.com wrote: It seems like a browser will have to essentially stop rendering until it has finished downloading the entire .zip and examined it. I think mitigating this is why there are optional manifests. I agree that if there's no manifest, this is really, really painful. I think manifests should be made mandatory. PK Do you mean external manifests? Either way, the browser cannot start a download for any external resource until it downloads and parses out the manifest.txt for every resource bundle seen in the page so far. Well, it can start the downloads, but it might have to throw them away, and it definitely can't actually make use of their contents. In this way it's a bit like the current implementation of optimistic parallel script fetching. Whether it is pulling the manifest out of a .zip file or as a .txt by itself doesn't matter much, it's still an extra HTTP round-trip before any content can be downloaded (including content that is not bundled at all). True. It's just not a delay until the .zip file has completed its download. I agree that even with a manifest, this is suboptimal. I think the decision to incorporate this in Fx 3.7 may be premature. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] plugin example is not working !!
Hi guys, I installed Webkit on ubuntu 9.04 , then I run some plugins code in folder WebKitExamplePlugins seems to be not working . those samples code are developed on Mac , problems is I all develop my code on Linux . I am not familiar with Mac . is there anyone give me some suggestions then I can get start to know how and what plugins is ? BRs Kevin ... ___ 您的生活即時通 － 溝通、娛樂、生活、工作一次搞定！ http://messenger.yahoo.com.tw/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] How do you set the http proxy for use by webkit gtk port?
I've read somewhere that you can set the environment http_proxy variable before launching a webkit-based browser on linux. I tried that on my fedora and it didn't work. Any ideas? Luying ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Multitouch support for QtWebKit on gitorious experimental branch
Very nice work! This is promising! - Mohamed Mansour On Thu, Oct 15, 2009 at 4:56 AM, jonni.raini...@nokia.com wrote: FYI, we have just released experimental branch of multitouch support of QtWebKit for Windows7 on gitorious. More information: demo videos, source code and binaries, and a small developer guide how to use Touch Manipulate API's(draft versions) and CSS transforms, animations and transitions are available here: http://opensource.nokia.com/Starlight We are currently cleaning up the code in gitorious and are hoping to submit patches to webkit.org in the near future. Regards, Jonni and the rest of the Starlight team ___ 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] is enchant optional?
Hi, Webkit depend on enchant for spell check, is this optional? If does, how can i disable it? BR, -Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Compilation Errors
Iam trying to complie WebKit-r50048 in CentOS 5 machine.I have Qt version 4.2.1 installed and when i run export WEBKITOUTPUTDIR=`pwd`/qtbuild export QTDIR=/usr/lib64/qt4 export PATH=/usr/lib64/qt4/bin:$PATH *./build-webkit --makeargs=-j20 -s --no-video --release* I get the following errors.Not sure what Iam missing.Can someone help me on this.? pcre.pri:16: Function[addExtraCompiler] multiply defined. pcre.pri:16: Unterminated conditional block at end of file Reading /home/shyam/webkit_source_oct26/WebKit-r50048/WebKit/qt/QtLauncher/QtLauncher.prqtbuild/Release/WebKit/qt/QtLauncher] Reading /home/shyam/webkit_source_oct26/WebKit-r50048/WebKit/qt/QGVLauncher/QGVLauncher.s/qtbuild/Release/WebKit/qt/QGVLauncher] Reading /home/shyam/webkit_source_oct26/WebKit-r50048/WebKit/qt/tests/ tests.pro [/home/slease/WebKit/qt/tests] Reading /home/shyam/webkit_source_oct26/WebKit-r50048/WebKit/qt/tests/qwebframe/qwebfraipts/qtbuild/Release/WebKit/qt/tests/qwebframe] Reading /home/shyam/webkit_source_oct26/WebKit-r50048/WebKit/qt/tests/qwebpage/qwebpagets/qtbuild/Release/WebKit/qt/tests/qwebpage] Reading /home/shyam/webkit_source_oct26/WebKit-r50048/WebKit/qt/tests/qwebelement/qwebe/Scripts/qtbuild/Release/WebKit/qt/tests/qwebelement] Reading /home/shyam/webkit_source_oct26/WebKit-r50048/WebKit/qt/tests/qgraphicswebview/ebKitTools/Scripts/qtbuild/Release/WebKit/qt/tests/qgraphicswebview] Reading /home/shyam/webkit_source_oct26/WebKit-r50048/WebKit/qt/tests/qwebhistoryinterfr50048/WebKitTools/Scripts/qtbuild/Release/WebKit/qt/tests/qwebhistoryinterface] Reading /home/shyam/webkit_source_oct26/WebKit-r50048/WebKit/qt/tests/qwebplugindatabas48/WebKitTools/Scripts/qtbuild/Release/WebKit/qt/tests/qwebplugindatabase] Reading /home/shyam/webkit_source_oct26/WebKit-r50048/WebKit/qt/tests/qwebview/qwebviewts/qtbuild/Release/WebKit/qt/tests/qwebview] Reading /home/shyam/webkit_source_oct26/WebKit-r50048/WebKit/qt/tests/qwebhistory/qwebh/Scripts/qtbuild/Release/WebKit/qt/tests/qwebhistory] Reading /home/shyam/webkit_source_oct26/WebKit-r50048/WebKitTools/DumpRenderTree/qt/Dumpools/Scripts/qtbuild/Release/WebKitTools/DumpRenderTree/qt] Reading /home/shyam/webkit_source_oct26/WebKit-r50048/WebKitTools/DumpRenderTree/qt/ImagScripts/qtbuild/Release/WebKitTools/DumpRenderTree/qt] Reading /home/shyam/webkit_source_oct26/WebKit-r50048/WebKitTools/DumpRenderTree/qt/Test6/WebKit-r50048/WebKitTools/Scripts/qtbuild/Release/WebKitTools/DumpRenderTree/qt/TestNe /bin/sh: line 0: cd: generatedrelease: No such file or directory make[1]: *** [generatedreleaseCSSPropertyNames.cpp] Error 1 make[1]: *** Waiting for unfinished jobs /bin/sh: line 0: cd: generatedrelease: No such file or directory make[1]: *** [generatedreleaseCSSValueKeywords.c] Error 1 regards, krithi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Text Input does not work running WebKit/GTK+/Directfb
Hello Mike. I think one person indicated that ICU was not built correctly. I think my ICU is ok, so how do I prove otherwise. This looks like an ICU issue to me. ICU will sometimes appear to build correctly, but will not shout about certain build problems that can arise whilst cross-compiling. I've seen this issue when cross-compiling for ARM. Check the build logs for ICU, and see if there's anything that looks like this: ./out/tmp/icudt42l_dat.o: file not recognized: File format not recognized collect2: ld returned 1 exit status Error generating package data. After that point, the build system appears to function normally. If you don't see that error, then you're looking at a different problem. Jacob -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of mike999 Sent: 05 October 2009 15:27 To: webkit-dev@lists.webkit.org Subject: [webkit-dev] Text Input does not work running WebKit/GTK+/Directfb I am having a problem running Webkit. I downloaded a version (38297) several months ago, and got it building and running on Ubuntu Linux. I have also ported it to run on a PPC platform, using GTK+ and DirectFB on my PPC hardware However, when I run my port on the PPC hardware, I see a couple unexpected behaviours. I have spend several days trying to track down the root cause, but not luck yet. I am running GtkLauncher demo program. Here is a summary of what I see 1. Text input works if I enter text in, for example, the URL field of the browser. 2. When I enter text in a HTML Text Input Element, it does not show up 3. Any initial value that is specified for a HTML Text Input Element does not appear. I have seen others post problems like this, but no conclusive indication of what the problem was, or more importantly how to find what the problem is. I think one person indicated that ICU was not built correctly. I think my ICU is ok, so how do I prove otherwise. Finally, I do see the input events getting dispatched into WebCore::EventTargetNode::dispatchEvent - Mike -- View this message in context: http://www.nabble.com/Text-Input-does-not-work-running-WebKit- GTK%2B-Directfb-tp25751468p25751468.html Sent from the Webkit mailing list archive at Nabble.com. ___ 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] [TEXT] spaces are shown as newline
Hi all ~ I've spent several months to build Webkit and depending libraries using RVCT. First, I built webkit for WindowsXP and then used those generated codes for my ARM platform. And now I can see text HTML rendered on my target. Problem is spaces are shown as newline. That is, Hello World Good Morning is rendered as Hello World Good Morning And similarly, each Korean characters are rendered with newline. Any guess ~? Son -- View this message in context: http://www.nabble.com/-TEXT--spaces-are-shown-as-newline-tp26070379p26070379.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Qt4.6 + Webkit Trunk Javascript Default values issue
Hello there! I am wondering if anyone (especially from the Qt team who ported the webkit to Qt4.6) has any pointers or idea about this issue I am seeing on QtLauncher. When a prompt is issued using Javascript and the user presses OK without entering anything in the text input box (leaving the default unchanged), then the following test should pass, it fails with Qt4.6 + webkit trunk using QtLauncher, but passes on safari 4.x. --- script type=text/ecmascript var RESULTS = ERROR; var msg = Accept this message without changing the default value:; var retVal = prompt(msg); if((retVal==undefined)||(retVal==)) RESULTS=SUCCESS ; /script --- It seems like the encoding of undefined string in the JSValue object is incorrect and the IsUndefinedOrNull() check is failing. Any pointers are greatly appreciated. Thanks Manish ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] jit for arm
Hi, when i reading the jit for arm source code, i am not very clear the functionality of the flowing functions: ctiTrampoline ctiVMThrowTrampoline ctiOpThrowNotCaught could you explain to me? and another question is that: in cacheFlush function, why the system call number is 0xf0002? if it is defined by the toolchain? thanks! BR, Jeff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] how to run mozilla test cases one by one using JSC
Hi, I bring up webkit with jit on my stb box. I want to test the jit if it is fine. When i run the mozilla test cases, i found that it need the perl tools. But my platform has not the perl environment, my question is that: can i run the test cases one by one under shell environment? such us ./jsc -f .js and can you tell me how to do this? when i run ./jsc -f ./emac/array/15-4.1.js, it always exit with code 3. That means it get error. BR, Jeff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] how to run mozilla test cases one by one using JSC
Hi, I bring up webkit with jit on my stb box. I want to test the jit if it is fine. When i run the mozilla test cases, i found that it need the perl tools. But my platform has not the perl environment, my question is that: can i run the test cases one by one under shell environment? such us ./jsc -f .js and can you tell me how to do this? when i run ./jsc -f ./emac/array/15-4.1.js, it always exit with code 3. That means it get error. BR, Jeff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKit on the server side
Hi, We are working on a new application server that uses WebKit for server-side JavaScript execution (and remote JavaScript debugging too). However, we can not use WebKit as is because we can not link with any of the GUI libraries and WebKit does. Instead, we compile just the JavaScriptCore part for JS execution. So my question is, are there any plans in the future to refactor or redesign WebKit to be more suitable for server environment? Would this, in your opinion, interest the WebKit community? For example, the first thing we had to deal with is the JS debugger. Debugger interface is defined in JavaScriptCore but its implementation lives in WebCore. Most of the debugger's implementation is abstract except for the part which sends event notifications to pages and frames objects which are GUI dependent and so can not be used in a faceless server application. So we basically copied the source of the existing debugger, commented out GUI related calls and added some stuff to transform it into a debugger which can be controlled remotely over the network. I would be happy to contribute to the WebKit project to add a layer of abstraction to the existing debugger implementation to cut its dependence on GUI and move it to JavaScriptCore from WebCore's inspector. Another example would be the XMLHttpRequest class implementation which exists in WebCore. In many indirect ways it depends on GUI even though it should not. As such, we can not simply expose it in our JavaScript environment on a faceless server. There are many other classes like it. All in all, so far it has been great fun to make the WebKit code run on the server side. I just wanted to raise awareness of the needs of server-side developers. -Sergiy Temnikov, Wakanda Server Architect Wakanda Software ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] how to run mozilla test cases one by one using JSC
You should simply copy the entire command line you see in the run-javascriptcore-tests output, eg. /path/to/jsc -s -f ./ecma/shell.js -f ./ecma/Date/15.9.5.17.js --Oliver On Nov 6, 2009, at 12:14 AM, ll Jefferry wrote: Hi, I bring up webkit with jit on my stb box. I want to test the jit if it is fine. When i run the mozilla test cases, i found that it need the perl tools. But my platform has not the perl environment, my question is that: can i run the test cases one by one under shell environment? such us ./jsc -f .js and can you tell me how to do this? when i run ./jsc -f ./emac/array/15-4.1.js, it always exit with code 3. That means it get error. BR, Jeff ___ 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] Unexpected Outage: commit-queue
Update: The queue is still down. I tried turning it on this morning and of the 5 patches I let it process, it rejected 4 of them due to https://bugs.webkit.org/show_bug.cgi?id=31461 before I turned it off. Good news: some progress has been made towards understanding https://bugs.webkit.org/show_bug.cgi?id=30835 (which is likely the same root cause as https://bugs.webkit.org/show_bug.cgi?id=31461). I'll post again when the queue is back on. -eric On Fri, Nov 13, 2009 at 6:32 PM, Eric Seidel e...@webkit.org wrote: I've turned off the commit-queue until we can find a solution to https://bugs.webkit.org/show_bug.cgi?id=31461. The commit-queue was rejecting more than half the patches queued in it due to that bug, rendering it useless. I'll post to webkit-dev once the queue is turned on again (hopefully Monday). -eric p.s. You can always check the status of the queue by loading http://webkit-commit-queue.appspot.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] jit for arm
On Nov 4, 2009, at 8:37 AM, ll Jefferry wrote: Hi, when i reading the jit for arm source code, i am not very clear the functionality of the flowing functions: ctiTrampoline This code is used when entering from the C runtime into JIT generated code. JIT generated code does not necessarily respect C calling conventions, so this routine sets up the stack frame, preserves registers, etc, as necessary to allow the JIT code to be run. ctiVMThrowTrampoline To perform certain operations the JIT will call back into C code. Usually the C callback can just return in a perfectly normal fashion and continue execution once it has completed, however in the case that an exception is thrown special handling is required to change the control flow. The return address of the C callback is instead changed to point to this, and this piece of code handles looking up the exception handler at which execution will be resumed. ctiOpThrowNotCaught This is used to from within cti_op_throw, which implements the 'throw' keyword in JavaScript. The cti_op_throw method will attempt to look up a handler routine that catches the exception. However if the exception is not caught it is necessary to force an early termination of JIT execution. The cti_op_throw C callback always modifies its return address, either to point to the code for the appropriate exception handler to catch the exception, or to ctiOpThrowNotCaught if no handler is found. could you explain to me? and another question is that: in cacheFlush function, why the system call number is 0xf0002? if it is defined by the toolchain? Zoltan, Gabor? thanks! BR, Jeff ___ 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] WebScripting protocol: valueForUndefinedKey: never gets called
Hi Geoffrey, Sure, I'll file a bug report for you. About your workaround though: wouldn't invokeUndefinedMethodFromWebScript:withArguments: only be called when the user tries to call a method that is not explicitly exposed to Javascript? Say for instance, that instead of calling a method by writing: x.test(), I would want to get it as a property by writing var y = x. test (I could wrap the selector in an object implementing the WebScripting protocol, and override invokeDefaultMethodWithArguments:). This wouldn't be solved by your workaround, or am I mistaken? I'm kind of desperate for a solution, even if temporary, since this (potential) bug voids the entire route we had in mind for our reflection layer. Any help or pointers you could offer me would be greatly appreciated! Cheers, Eddy On Tue, Nov 17, 2009 at 9:02 PM, Geoffrey Garen gga...@apple.com wrote: Hi Eddy. This seems like a bug to me. Would you be willing to file it at bugs.webkit.org? I have a guess at a possible work-around. In the class where you've implemented valueForUndefinedKey:, try also implementing invokeUndefinedMethodFromWebScript:withArguments:. Thanks, Geoff On Nov 17, 2009, at 7:37 AM, Eddy Bruël wrote: Hi everybody, I am in the process of writing some code in ObjC, which would allow me to make calls from Javascript to C++ objects implementing a simple reflection interface (it basically allows you to associated indices with names, and perform operations such as getting/setting/calling on these indices). In order to do this, I created a simple ObjC wrapper object around the C++ interface, which implements the WebScripting protocol. However, since this wrapper object does not have any member variables (they are all hidden behind the C++ interface), I cannot expose these to Javascript directly. Instead, I've tried to make them available using KVC, specifically by using the methods valueForUndefinedKey: and setValue:forUndefinedKey:. For isKeyExcludedFromWebScript: and isSelectorExcludedFromWebScript: I simply always return YES. Setting properties like this seems to work fine. The method get called, and I simply forward it to the reflection interface. Getting properties, on the other hand, does not seem to work: valueForUndefinedKey: simply does not get called. At all. I found an entry on the Apple mailing lists of somebody seemingly having the same problem as me. Unfortunately, there was no answer: http://lists.apple.com/archives/webkitsdk-dev/2008/Oct/msg00021.html Am I overlooking something? Are there any other methods I need to override in order for this to work? Or is it simply a bug in WebKit, since this approach to exposing properties seems to be non-standard, at least. Any feedback on this issue would be very much appreciated! :-) Cheers, Eddy ___ 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] WebKit on the server side
The Chromium port of WebKit already acts very much like a headless build of WebKit owing to the Chromium sandbox, which denies the WebKit process access to most features of the system, including the GUI system. The interface lives here: http://trac.webkit.org/browser/trunk/WebKit/chromium Documentation is still very sparse, but the basic idea is that the embedder must implement WebKitClient, which provides access to some of the required system services. If you are interested, I would start by looking at the Chromium WebKit port to Linux. Cheers, -Darin On Tue, Nov 17, 2009 at 6:16 AM, Sergiy Temnikov sergiy.temni...@4d.comwrote: Hi, We are working on a new application server that uses WebKit for server-side JavaScript execution (and remote JavaScript debugging too). However, we can not use WebKit as is because we can not link with any of the GUI libraries and WebKit does. Instead, we compile just the JavaScriptCore part for JS execution. So my question is, are there any plans in the future to refactor or redesign WebKit to be more suitable for server environment? Would this, in your opinion, interest the WebKit community? For example, the first thing we had to deal with is the JS debugger. Debugger interface is defined in JavaScriptCore but its implementation lives in WebCore. Most of the debugger's implementation is abstract except for the part which sends event notifications to pages and frames objects which are GUI dependent and so can not be used in a faceless server application. So we basically copied the source of the existing debugger, commented out GUI related calls and added some stuff to transform it into a debugger which can be controlled remotely over the network. I would be happy to contribute to the WebKit project to add a layer of abstraction to the existing debugger implementation to cut its dependence on GUI and move it to JavaScriptCore from WebCore's inspector. Another example would be the XMLHttpRequest class implementation which exists in WebCore. In many indirect ways it depends on GUI even though it should not. As such, we can not simply expose it in our JavaScript environment on a faceless server. There are many other classes like it. All in all, so far it has been great fun to make the WebKit code run on the server side. I just wanted to raise awareness of the needs of server-side developers. -Sergiy Temnikov, Wakanda Server Architect Wakanda Software ___ 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] Staging WebSocket protocol deployment
Hi, Maciej, I vote for (3). Yuzo On Wed, Nov 18, 2009 at 6:08 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 15, 2009, at 5:18 PM, Yuzo Fujishima wrote: Hi, I'm against prefixing with webkit- because of the following reasons. Reason 1: It connotes that the feature is experimental. That means there will be less developers seriously use that feature. Without serious use, we'll have less serious feedbacks from the real world. If the Web Socket has serious flaws, we should rather know them sooner than later. I'd say only serious uses can help us find the flaws faster. I think this captures the root of the disagreement. Personally, I would like to do something to send the message that WebSocket is still somewhat experimental. It's true that the spec has been in development for a long time. But we are only now seeing the first client-side and server-side implementations. A number of issues were discovered in that process, and I'd personally like to see some more experimental implementations before we lose the ability to make incompatible changes. See below for some specific suggestions. Reason 2: What should other browser vendors do? Should they use chrome-ws, firefox-ws, ie-ws, opera-ws, ..., etc? I believe at least developers will not happy with that. If the vendors need to reach the consensus on the common experimental name, say prelim-ws, then why not just use ws instead? Historically, we haven't had a problem with WebKit-prefixed features - it seems that other browser vendors implement under their own prefix and content adapts to deal. Anyway, getting back to the suggestions... I think it's reasonable at this point to indicate that the WebSocket protocol is somewhat experimental (probably more so than the API). I will recommend doing something along those lines for the next release of Safari. If we can get rough consensus within the WebKit community that we should label the protocol experimental, and how we should do so, then we can just make the change in WebKit and vendor releases will follow along. Here is an extended list of ideas (ones that I think are practically doable): 1) Change the URI schemes to webkit-ws and webkit-wss - the vendor prefix strategy. 2) Change the URI schemes to x-ws and x-wss - a vendor-independent experimental prefix. 3) Don't change the URI schemes at all, but communicate in some public way that the protocol is not completely locked down yet, and we are largely looking for early adopter feedback. We could do this in the form of a WebKit blog post, for example. And we could reinforce that in developer documentation for WebKit-based products. 4) Support both unprefixed and prefixed URI schemes, and in addition publicize that we will maintain compatibility for the prefixed URI scheme but the unprefixed version may have to change (combo of 3 and either 1 or 2). 5) Make the feature runtime switchable (using some semi-hidden UI) and off by default. I'd like to hear opinions on which of these is best. I'd also like to hear if anyone feels that we should send the message that the WebSocket Protocol is production quality and we promise full compatibility going forward. Does anyone truly feel this way? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making browsers faster: Resource Packages
I don't see much value in this proposition. For CSS and JS, people will need to run a script to generate the ZIP file. That's what they already do when combining files. And they get more value by combining since they get performance improvements for all browsers, not just the one supporting resource-packages. For CSS Sprites, the W3C is working on making it better with http://www.w3.org/TR/css3-images/. Maybe you should put some efforts on this spec. And again, with the actual situation, the code is maybe ugly but you get performance benefits for all browsers. The only benefit would eventually be for inline images. But you can't generate a static ZIP file for such moving content so I don't see a lot of persons taking advantage of this proposition for that kind of content. Thinking out loud, maybe something like img src=file.png from=file.zip would be more appropriate for that particular kind of content. This way, browsers now upfront if a file can be found in a package. I sure like the idea of trying to reduce the number of HTTP requests, but I don't think it's the right solution. On Tue, Nov 17, 2009 at 11:19 PM, Alexander Limi l...@mozilla.com wrote: Good people of Webkit! We'd all like for the web to be faster, and therefore I'd love your feedback on my proposal — it would be great to see support for this in additional browsers, not just Firefox: http://limi.net/articles/resource-packages/ Summary: What if there was a backwards compatible way to transfer all of the resources that are used on every single page in your site — CSS, JS, images, anything else — in a single HTTP request at the start of the first visit to the page? This is what Resource Package support in browsers will let you do. Looking forward to hear your thoughts on this. Thanks! -- Alexander Limi · Firefox User Experience · http://limi.net ___ 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] Making browsers faster: Resource Packages
(Adding in some of the people involved with Resource Packages earlier to this thread, so they can help me out — I'm just a lowly UI designer, so some of these questions have to be answered by people that know how browsers work. I'm just the messenger. Hope you don't mind, guys, and remember that webkit-dev requires you to sign up before you can post.) On Tue, Nov 17, 2009 at 2:44 PM, Peter Kasting pkast...@google.com wrote: I have read the whole document, but I read it quickly, so please do point out places where I've overlooked an obvious response. This is what everyone does, so no worries, happy to clarify. 95% of the this is why this won't work statements are actually answered by the article in some way. But I guess I shouldn't be surprised. :) Reduced parallelism is a big concern of mine. Lots of sites make heavy use of resource sharding across many hostnames to take advantage of multiple connections, which this defeats. If you package up everything in a single zip file, yes. Realistically, if you have a lot of resources, you'd want to spread them out over several files to increase parallelism. Also, there's usually resources that are page-specific (e.g. belong to the article being rendered). As with everything, there are possibilities to use this the wrong way, and packaging up everything in one zip file will definitely affect parallelism. Don't do that. I am concerned about the instruction to prefer the packaged resources to any separate resources. This seems to increase the maintenance burden since you can never incrementally override the contents of a package, but always have to repackage. This is something we could look at, of course. There are easy ways to invalidate the zip using ETags etc. If an author has resources only used on some pages, then he can either make multiple packages (more maintenance burden and exacerbates problem above), or include everything in one package (may result in downloading excessive resources for pages where clients don't need them). I don't think it's unreasonable to expect most big sites to have a standard core of resources they use everywhere. It's important not to try to put *everything* in resource packages, just the stuff that should be present everywhere (and the specialized thumbnail search result case I mentioned). You note that SPDY has to be implemented by both UAs and web servers, but conversely this proposal needs to be implemented by UAs and _authors_. I would rather burden the guys writing Apache than the guys making webpages, and I think if a technique is extremely useful, it's easier to get support into Apache than into, say, 50% of the webpages out there. There's no damage if you *don't* do this as a web author. If you care enough to do CSS spriting and CSS/JS combining, this gives you a more maintainable, easier, faster solution. On Tue, Nov 17, 2009 at 3:00 PM, James Robinson jam...@google.com wrote: It seems like a browser will have to essentially stop rendering until it has finished downloading the entire .zip and examined it. No. That's why the manifest is there, since it can be read early on, so the browser doesn't have to block. I see a lot of I don't think this will work or I don't think this will be any faster here. I guess I should get someone to help me create some reasonable benchmarks and show what the difference would be. Maybe Steve Souders or someone else that is better at this stuff than me can help out with some data. On Tue, Nov 17, 2009 at 3:02 PM, Peter Kasting pkast...@google.com wrote: I think mitigating this is why there are optional manifests. I agree that if there's no manifest, this is really, really painful. I think manifests should be made mandatory. The manifests *are* mandatory. Without a manifest, it won't do anything (ie. proceed to load the resources as usual), since that would block page loads, which is not an option. On Tue, Nov 17, 2009 at 3:12 PM, Simon Fraser simon.fra...@apple.comwrote: If you require a manifest, why not pick an archive format where there's a TOC which is guaranteed to be at the head of the file, which the browser can parse without having to wait for the entire file to download? If there are other formats that can a) be streamed and unpacked in partial state, and b) is common enough that people will actually be able to use it, let me know. The tar format is sequential, and (I think) has the header first, but doesn't do compression. If you add gzip to that, you can't partially unpack, which will block page downloads. You could of course argue that using only tar (without gzip) could work, and I think we're open to supporting that, if those assumptions are correct — I haven't looked at the details for that yet. -- Alexander Limi · Firefox User Experience · http://limi.net ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making browsers faster: Resource Packages
On Tue, Nov 17, 2009 at 3:00 PM, James Robinson jam...@google.com wrote: On Tue, Nov 17, 2009 at 2:19 PM, Alexander Limi l...@mozilla.com wrote: Good people of Webkit! We'd all like for the web to be faster, and therefore I'd love your feedback on my proposal — it would be great to see support for this in additional browsers, not just Firefox: http://limi.net/articles/resource-packages/ Summary: What if there was a backwards compatible way to transfer all of the resources that are used on every single page in your site — CSS, JS, images, anything else — in a single HTTP request at the start of the first visit to the page? This is what Resource Package support in browsers will let you do. Looking forward to hear your thoughts on this. It seems like a browser will have to essentially stop rendering until it has finished downloading the entire .zip and examined it. I think that's not entirely true. In zip archives the manifest comes first and can be examined while the rest of the body is still downloading. This will most likely slow down the time taken to render parts of the page as they arrive. From the blog post: A given browser will probably block downloading any resources until the lists of files that are available in resource packages have been accounted for — or there may be a way to do opportunistic requests or similar, we leave this up to the browser vendor unless there’s a compelling reason to specify how this should work. This also means that a browser would have to stop tokenizing the HTML when it hits the next script src= tag, since it would be unable to know if the javascript was in the bundled zip or not. This seems to go against the idea that as much of the page be rendered as fast as possible. - James Thanks! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making browsers faster: Resource Packages
On Tue, Nov 17, 2009 at 5:36 PM, Alexander Limi l...@mozilla.com wrote: (Adding in some of the people involved with Resource Packages earlier to this thread, so they can help me out — I'm just a lowly UI designer, so some of these questions have to be answered by people that know how browsers work. I'm just the messenger. Hope you don't mind, guys, and remember that webkit-dev requires you to sign up before you can post.) On Tue, Nov 17, 2009 at 2:44 PM, Peter Kasting pkast...@google.com wrote: I have read the whole document, but I read it quickly, so please do point out places where I've overlooked an obvious response. This is what everyone does, so no worries, happy to clarify. 95% of the this is why this won't work statements are actually answered by the article in some way. But I guess I shouldn't be surprised. :) Reduced parallelism is a big concern of mine. Lots of sites make heavy use of resource sharding across many hostnames to take advantage of multiple connections, which this defeats. If you package up everything in a single zip file, yes. Realistically, if you have a lot of resources, you'd want to spread them out over several files to increase parallelism. Also, there's usually resources that are page-specific (e.g. belong to the article being rendered). As with everything, there are possibilities to use this the wrong way, and packaging up everything in one zip file will definitely affect parallelism. Don't do that. If the contents are spread across N zip files then the browser still has to download (at least part of) N files in order to see all the manifests before it can start fetching other resources. The page-specific resources end up getting blocked behind all of the manifest downloads. If resource bundles are allowed to include other resource bundles (and I see nothing in the spec about this), then each of the N downloads would have to be made serially since the browser would have to check the manifest of each bundle to see if it includes any of the remaining ones. I think this line of concerns would be lesser if the author could declare the contents of the manifest in the HTML itself to avoid an extra download or give some sort of explicit signal to the browser that a given resource was not in any resource bundle. The downside of this is that it increases the HTML's size even more which is a big loss on browsers that do not support this. I am concerned about the instruction to prefer the packaged resources to any separate resources. This seems to increase the maintenance burden since you can never incrementally override the contents of a package, but always have to repackage. This is something we could look at, of course. There are easy ways to invalidate the zip using ETags etc. If an author has resources only used on some pages, then he can either make multiple packages (more maintenance burden and exacerbates problem above), or include everything in one package (may result in downloading excessive resources for pages where clients don't need them). I don't think it's unreasonable to expect most big sites to have a standard core of resources they use everywhere. It's important not to try to put *everything* in resource packages, just the stuff that should be present everywhere (and the specialized thumbnail search result case I mentioned). You note that SPDY has to be implemented by both UAs and web servers, but conversely this proposal needs to be implemented by UAs and _authors_. I would rather burden the guys writing Apache than the guys making webpages, and I think if a technique is extremely useful, it's easier to get support into Apache than into, say, 50% of the webpages out there. There's no damage if you don't do this as a web author. If you care enough to do CSS spriting and CSS/JS combining, this gives you a more maintainable, easier, faster solution. On Tue, Nov 17, 2009 at 3:00 PM, James Robinson jam...@google.com wrote: It seems like a browser will have to essentially stop rendering until it has finished downloading the entire .zip and examined it. No. That's why the manifest is there, since it can be read early on, so the browser doesn't have to block. I see a lot of I don't think this will work or I don't think this will be any faster here. I guess I should get someone to help me create some reasonable benchmarks and show what the difference would be. Maybe Steve Souders or someone else that is better at this stuff than me can help out with some data. Yes, actual numbers would be nice to have. - James On Tue, Nov 17, 2009 at 3:02 PM, Peter Kasting pkast...@google.com wrote: I think mitigating this is why there are optional manifests. I agree that if there's no manifest, this is really, really painful. I think manifests should be made mandatory. The manifests *are* mandatory. Without a manifest, it won't do anything (ie. proceed to load the resources as usual), since that
Re: [webkit-dev] Making browsers faster: Resource Packages
On Tue, Nov 17, 2009 at 5:53 PM, James Robinson jam...@google.com wrote: Yes, actual numbers would be nice to have. Steve Souders just emailed me some preliminary numbers from a bunch of major web sites, so that should be on his blog shortly. -- Alexander Limi · Firefox User Experience · http://limi.net ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebScripting protocol: valueForUndefinedKey: never gets called
Hi Eddy. Sure, I'll file a bug report for you. Thanks! About your workaround though: wouldn't invokeUndefinedMethodFromWebScript:withArguments: only be called when the user tries to call a method that is not explicitly exposed to Javascript? Yes. To clarify, I think that the simple fact of responding to the selector invokeUndefinedMethodFromWebScript:withArguments: will start making valueForUndefinedKey: work. I'm not saying that invokeUndefinedMethodFromWebScript:withArguments: needs to do anything interesting. It can be empty. (That's my guess from looking at the code, anyway. Worth a shot.) Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making browsers faster: Resource Packages
On Tue, Nov 17, 2009 at 5:36 PM, Alexander Limi l...@mozilla.com wrote: On Tue, Nov 17, 2009 at 2:44 PM, Peter Kasting pkast...@google.com wrote: Reduced parallelism is a big concern of mine. Lots of sites make heavy use of resource sharding across many hostnames to take advantage of multiple connections, which this defeats. If you package up everything in a single zip file, yes. Realistically, if you have a lot of resources, you'd want to spread them out over several files to increase parallelism. Also, there's usually resources that are page-specific (e.g. belong to the article being rendered). As with everything, there are possibilities to use this the wrong way, and packaging up everything in one zip file will definitely affect parallelism. Don't do that. But at this point it's not clear what the site author should do. *Any* packaging reduces parallelism somewhat. How much do you reduce parallelism? Best practices vary dramatically depending on the details of the user's connection. I realize some of these issues already exist when sites try to determine how to shard their resource servers, but if you want to split your resources among several packages *today*, you can put all the images in one file, all the scripts in one file, etc., today, and this proposal doesn't buy terribly much over that. (Plus it has costs, see below.) You note that SPDY has to be implemented by both UAs and web servers, but conversely this proposal needs to be implemented by UAs and _authors_. I would rather burden the guys writing Apache than the guys making webpages, and I think if a technique is extremely useful, it's easier to get support into Apache than into, say, 50% of the webpages out there. There's no damage if you *don't* do this as a web author. If you care enough to do CSS spriting and CSS/JS combining, this gives you a more maintainable, easier, faster solution. Neither proposal does harm when people don't implement it. What I am saying is that there's much more of a burden to try and get this to happen on a per-site-author basis than a per-web-server-codebase basis. And with a technique that needs expertise not to backfire, I'm definitely interested in not forcing each site author to make individual decisions about how to use it. I think mitigating this is why there are optional manifests. I agree that if there's no manifest, this is really, really painful. I think manifests should be made mandatory. The manifests *are* mandatory. Without a manifest, it won't do anything (ie. proceed to load the resources as usual), since that would block page loads, which is not an option. Your doc explicitly says manifests are optional: To give the browser the ability to know up front what files are in the zip file without reading the entire file first, we support an *optional* manifest file that can contain this information. (emphasis mine) As I noted, even with a manifest, you're introducing extra overhead before the browser knows how to handle other referenced resources, although it is only the overhead of contacting the web server and obtaining the manifest, rather than the overhead of obtaining the entire bundle. James Robinson does a good job in his latest message of covering some of the issues here in more detail. In the end, the initial proposal comes across a bit like just bundle everything up in one archive!, but as you note, doing that will _harm_ page load speeds in many cases. The actual usage of this feature needs to be carefully considered by site authors, and ends up providing capabilities very similar to spriting and combining script files, except with the additional problem that the browser has to obtain manifests before it knows how to process any resources referenced in the document. This just doesn't feel like a very good tradeoff to me. I agree with everyone who would like to see numbers. Of course, good measurements here are extremely hard (as we've found while working on SPDY), so I suspect providing meaningful, reliable ones that cover all the relevant cases might take quite a bit of doing. I will be interested to see what Steve Souders has come up with, and especially what sort of conditions lead to the numbers he has. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making browsers faster: Resource Packages
On Tue, Nov 17, 2009 at 6:01 PM, Peter Kasting pkast...@google.com wrote: Your doc explicitly says manifests are optional: To give the browser the ability to know up front what files are in the zip file without reading the entire file first, we support an *optional* manifest file that can contain this information. (emphasis mine) That's a leftover from the old proposal. Fixed. -- Alexander Limi · Firefox User Experience · http://limi.net ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Wed, Nov 18, 2009 at 6:08 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 15, 2009, at 5:18 PM, Yuzo Fujishima wrote: Hi, I'm against prefixing with webkit- because of the following reasons. Reason 1: It connotes that the feature is experimental. That means there will be less developers seriously use that feature. Without serious use, we'll have less serious feedbacks from the real world. If the Web Socket has serious flaws, we should rather know them sooner than later. I'd say only serious uses can help us find the flaws faster. I think this captures the root of the disagreement. Personally, I would like to do something to send the message that WebSocket is still somewhat experimental. It's true that the spec has been in development for a long time. But we are only now seeing the first client-side and server-side implementations. A number of issues were discovered in that process, and I'd personally like to see some more experimental implementations before we lose the ability to make incompatible changes. See below for some specific suggestions. Reason 2: What should other browser vendors do? Should they use chrome-ws, firefox-ws, ie-ws, opera-ws, ..., etc? I believe at least developers will not happy with that. If the vendors need to reach the consensus on the common experimental name, say prelim-ws, then why not just use ws instead? Historically, we haven't had a problem with WebKit-prefixed features - it seems that other browser vendors implement under their own prefix and content adapts to deal. Anyway, getting back to the suggestions... I think it's reasonable at this point to indicate that the WebSocket protocol is somewhat experimental (probably more so than the API). I will recommend doing something along those lines for the next release of Safari. If we can get rough consensus within the WebKit community that we should label the protocol experimental, and how we should do so, then we can just make the change in WebKit and vendor releases will follow along. Here is an extended list of ideas (ones that I think are practically doable): 1) Change the URI schemes to webkit-ws and webkit-wss - the vendor prefix strategy. 2) Change the URI schemes to x-ws and x-wss - a vendor-independent experimental prefix. 3) Don't change the URI schemes at all, but communicate in some public way that the protocol is not completely locked down yet, and we are largely looking for early adopter feedback. We could do this in the form of a WebKit blog post, for example. And we could reinforce that in developer documentation for WebKit-based products. 4) Support both unprefixed and prefixed URI schemes, and in addition publicize that we will maintain compatibility for the prefixed URI scheme but the unprefixed version may have to change (combo of 3 and either 1 or 2). 5) Make the feature runtime switchable (using some semi-hidden UI) and off by default. I'd like to hear opinions on which of these is best. I vote option (3). Even if we keep current protocol stack with prefixed URI, I'm wondering any websocket server implementation will keep compatibility with procotol of our prefixed URI.. Or, if some websocket server implementation keeps compatible with prefixed URI, I believe it's worse situation for future. -- ukai I'd also like to hear if anyone feels that we should send the message that the WebSocket Protocol is production quality and we promise full compatibility going forward. Does anyone truly feel this way? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] plugin example is not working !!
On Oct 7, 2009, at 4:51 AM, kevin631012 wrote: I installed Webkit on ubuntu 9.04 , then I run some plugins code in folder WebKitExamplePlugins seems to be not working . those samples code are developed on Mac , problems is I all develop my code on Linux . I am not familiar with Mac . It’s true that those example plug-ins are for the Mac platform and created by Apple. If someone else has a sample plug-in to contribute for other platforms that would be great. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] plugin example is not working !!
On Tue, Nov 17, 2009 at 10:08 PM, Darin Adler da...@apple.com wrote: On Oct 7, 2009, at 4:51 AM, kevin631012 wrote: I installed Webkit on ubuntu 9.04 , then I run some plugins code in folder WebKitExamplePlugins seems to be not working . those samples code are developed on Mac , problems is I all develop my code on Linux . I am not familiar with Mac . It’s true that those example plug-ins are for the Mac platform and created by Apple. If someone else has a sample plug-in to contribute for other platforms that would be great. The test plugin used by DumpRenderTree is cross-platform. Look in WebKitTools/DumpRenderTree for directories with Plugin in their name. DiamondX is a test plugin implementing the Xembed interface NPAPI on Linux uses. The author now works on Linux Flash so it is useful as a reference for The Plugin. http://multimedia.cx/diamondx/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] normalizing namespace indenting
On Nov 16, 2009, at 7:54 PM, Chris Jerdonek wrote:
First, it seems like the original motive was to avoid pointlessly indenting
nearly the whole file:
https://lists.webkit.org/pipermail/webkit-dev/2009-September/010002.html
So, I was wondering if we can clarify the rule to apply only to the outermost
namespace declaration.
Yes, I think we can.
(Consecutive declarations like namespace JSC { namespace WREC { would be
treated as a single declaration for the purpose of this rule.)
Neat idea, I think.
Second, do people prefer nested namespace blocks to end with the
fully-qualified name (e.g. // namespace JSC::WREC) or just the final name
(e.g. // namespace WREC)? I have seen both.
I prefer just the final name, but it’s an extremely mild preference!
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] plugin example is not working !!
Hi Darin, Check out the plugins in Mozilla which are NPAPI based. mozilla\modules\plugin\samples\npruntime... try this one especially.. This works on Linux platform.. by modifying the makefile... Thanks and Regards Rekha On Wed, Nov 18, 2009 at 11:38 AM, Darin Adler da...@apple.com wrote: On Oct 7, 2009, at 4:51 AM, kevin631012 wrote: I installed Webkit on ubuntu 9.04 , then I run some plugins code in folder WebKitExamplePlugins seems to be not working . those samples code are developed on Mac , problems is I all develop my code on Linux . I am not familiar with Mac . It’s true that those example plug-ins are for the Mac platform and created by Apple. If someone else has a sample plug-in to contribute for other platforms that would be great. -- Darin ___ 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] jit for arm
Hi, seems the original mail was sent to both webkit-dev and webkit-help. My reply was on webkit-help, and the discussion continued there. https://lists.webkit.org/pipermail/webkit-help/2009-November/000380.html Perhaps we should clarify better the purpose of these mailing lists, since if people can't decide which list is better for them, they do double posts. Zoltan On Nov 4, 2009, at 8:37 AM, ll Jefferry wrote: Hi, when i reading the jit for arm source code, i am not very clear the functionality of the flowing functions: ctiTrampoline This code is used when entering from the C runtime into JIT generated code. JIT generated code does not necessarily respect C calling conventions, so this routine sets up the stack frame, preserves registers, etc, as necessary to allow the JIT code to be run. ctiVMThrowTrampoline To perform certain operations the JIT will call back into C code. Usually the C callback can just return in a perfectly normal fashion and continue execution once it has completed, however in the case that an exception is thrown special handling is required to change the control flow. The return address of the C callback is instead changed to point to this, and this piece of code handles looking up the exception handler at which execution will be resumed. ctiOpThrowNotCaught This is used to from within cti_op_throw, which implements the 'throw' keyword in JavaScript. The cti_op_throw method will attempt to look up a handler routine that catches the exception. However if the exception is not caught it is necessary to force an early termination of JIT execution. The cti_op_throw C callback always modifies its return address, either to point to the code for the appropriate exception handler to catch the exception, or to ctiOpThrowNotCaught if no handler is found. could you explain to me? and another question is that: in cacheFlush function, why the system call number is 0xf0002? if it is defined by the toolchain? Zoltan, Gabor? thanks! BR, Jeff ___ 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
