Re: [webkit-dev] SharableScriptContext [was: GlobalScript in WebKit]
On Nov 30, 2009, at 11:47 PM, Adam de Boor wrote:
A worker context without the thread is close to what we're after, except for
the bit about how it doesn't do network stuff or timeouts.
Errr, what? Workers can do networking, timeouts -- xhr, setTimeout,
setInterval, etc is available to them so i'm not sure what you mean by that?
As for the DOM -- the only reason for a Worker not having access to the DOM is
because the only means for communication is postMessage which doesn't allow
pass by reference (and most/all DOM implementations assume single threaded
access). Assuming this magical object existed you would be better off thinking
of it as being an iframe without a document and with a lifetime unbounded by
its parent.
Fundamentally what we need is, a place for centralizing network access and
significant amounts of application state, and sharing large amounts of code,
that is independent of any single window, and can manipulate the DOM of an
arbitrary number of application windows that are either created by code in
this independent context, or created by the user through navigation. We'd
like to be able to create this context from an extension, so if a user wishes
to have instant access to their gmail, or facebook, or whatever, they could
choose to install an extension that would create this context when the
browser starts.
I'm not sure how this would work -- as far as I am aware extensions in chrome
make use of isolated worlds, which should prevent an extension from creating an
object that can be shared with any normal webpage, and of course the extension
would not be in the same origin as the page you're hoping for so wouldn't be
able to share anything anyway.
That said your whole extension for preloading concept seems like it could be
mostly duplicated by using the application cache -- you'd still get hit with
compilation time (theoretically once in this model) but compared with load time
compilation is inconsequential.
Shared workers fundamentally don't do the trick because (a) most of the code
in the application has nothing to do with accessing the server, and
everything to do with presenting the UI, so shared workers don't help with
sharing the code among multiple windows, and (b) we want the UI to be
immediately responsive, which means not waiting for a worker thread to get
back to the UI thread with data, so we'd be caching the data both in the UI
context and in the worker thread context, in which case we might as well just
go to the server.
Errr, if asking a worker for data is taking as long as a server request there's
a bug... I'm really not sure what you're saying here.
When using a named window, there are interesting race conditions (unless you
do something like the appcache suggestion to ensure the windows are in the
same process) when one is restoring the browser state on startup. The
significant challenge for the app developer is to deal with, when the named
window closes, in-flight non-idempotent XHRs and registered timeouts that
ought to be independent of any window, but that are tied to the named window.
Timeouts are easier to deal with (centralized timer manager that remembers
the deadline for each and reschedules in the context of the new named
window). Being able to reparent an XHR in flight would make handling the
transition easier
From what you're saying here it sounds like you're assuming the
SharedScript/GlobalScript concept would be guaranteed to be unique in all
normal (eg. single browser) cases (so in chromium potentially across multiple
processes), yet chromium developers have repeatedly stated that they would not
be shared across multiple processes.
--Oliver
a
On Mon, Nov 30, 2009 at 10:24 PM, Oliver Hunt oli...@apple.com wrote:
On Nov 30, 2009, at 10:12 PM, Dmitry Titov wrote:
At first look, this would solve same use cases as SharedScript. The
difference is that it has to be passed to participating windows explicitly.
Summing up, just for reference:
var mySharedScriptContext = new SharedScriptContext(foo.js);
mySharedScriptContext.onload = ...;
later:
var win = window.open(...);
win.functionThatTakesSharedScriptContext(mySharedScriptContext);
alternatively, later:
var win = window.getWindowByName(foo); // does not create a window if
there is no foo, searches in same process
if (win)
win.functionThatTakesSharedScriptContext(mySharedScriptContext);
and, possibly: add a list (regexp?) to App Cache manifest to describe the
set of URLs loaded into the same process to make them able to find each
other without relying on window.open().
The idea behind SharedScriptContext+getWindowByName was that it would be
possible to do (in your new window)
if (sharedWin = getWindowByName(OriginWindow))
sharedContext = sharedWin.sharedContext;
else {
name = OriginWindow;
sharedContext = new SharedScriptContext(foo.js);
}
At least that
Re: [webkit-dev] trac.webkit.org links via Google.com
On 2009-11-30, at 23:38, Yaar Schnitman wrote: A sitemap.xml file is a more modern way of telling Google how to crawl a site and the traffic can be throttled in Google's webmaster tools (http://www.google.com/webmasters/tools/). Creating a daily script that generates sitemap.xml for webkit's SVN repo should trivial. There are probably trac plugins that do that already. If done right, google crawler shouldn't produce much more load than an average developer doing a daily svn sync. Google isn't the only search engine we're concerned about. We need to prevent all search engines from hammering the repository, even those that don't support this technology. I can't find any information about the precedence of exclusions in robots.txt vs a sitemap so it's not clear whether that can be achieved without having to explicitly whitelist individual crawlers. If it is possible to use a sitemap without having to whitelist individual crawlers then we should investigate doing so. Suggesting it is trivial is being rather optimistic though. You'd need to dramatically restrict the set of content that is exposed for indexing to make it feasible. For instance: allow indexing only the content of files on trunk (no branches, tags, non-HEAD revisions). You'd also want to expose individual changesets to ensure that commit messages are indexed. But… from what I can see a sitemap only points at content that is available, it doesn't restrict what can be indexed. While we'd want individual changeset pages to be indexed we'd certainly not want it to follow every individual view diff link on such a page, nor would we want it to follow the numerous other links within the content back to previous revisions, other branches, tags, etc. Maybe there's something that I'm missing that makes sitemaps usable for this purpose though. - Mark smime.p7s Description: S/MIME cryptographic signature ___ 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
Is there any overlap there with this project: http://code.google.com/p/wkhtmltopdf/ ? On Nov 18, 2009, at 9:01 AM, Patrick Mueller wrote: Sergiy Temnikov wrote: Hi, We are working on a new application server that uses WebKit for server-side JavaScript execution (and remote JavaScript debugging too). ... 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. It would be interesting to see this. Open a bug and contribute a patch. There's two reasons I think this is interesting: - would be useful for embedded clients. For instance, if this is the current state-of-the-art for debugging Palm's WebOS apps, which are (in my understanding) running in WebKit - http://is.gd/4RKuh - then a remote debug interface would be incredibly useful, assuming you had a nice client. - just cleaning up the interfaces between the debugger and debugging clients to begin with would probably be useful. -- Patrick Mueller - http://muellerware.org ___ 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] Platform API for Uniscribe/ComplexTextController?
On Nov 29, 2009, at 10:27 AM, Kevin Ollivier wrote: Hi all, The wx port is starting to look at getting proper support for complex text, and one of the first places I started looking at was the Win and Mac port implementations. I noticed that the complex text code in FontWin.cpp and FontComplexTextMac.cpp is largely the same, passing the heavy lifting down to their respective complex text controllers, and I actually wondered if they could be merged if there were some tweaks to the APIs to make them compatible. That led me to wonder if we couldn't make ComplexTextController one of our platform classes and have USE() defines to determine the implementation. Then we could move the drawComplexText, floatWidthForComplexText, and offsetForPositionForComplexText into Font.cpp guarded by that USE() define. The wx port can provide the native font handles the Win/Mac controllers need, so it'd really be great if we could just add these into our build to get complex text support working without having to implement the complex text methods differently for each platform. BTW, I actually already did get UniscribeController compiling, actually, but on Windows I had to have the build script copy it to platform/graphics/wx because MSVC implicitly puts the current directory first on the path, which was causing it to pick up platform/graphics/win/FontPlatformData.h instead of the wx one when compiling that file. :( So that's something else that would need to be addressed if ports can start sharing these files. Thanks, Kevin Hi Kevin, This sounds like a generally good idea. ComplextTextController is already using USE() macros to select between Core Text and ATSUI. I am not entirely sure how the the *ComplexText() methods will be guarded in Font.cpp in your proposal. Are you suggesting something like #if USE(ATSUI) || USE(CORE_TEXT) || USE(UNISCRIBE) || … ? There are still some differences in behavior between ComplexTextController and UniscribeController, so you’d need to find a way to accommodate them or eliminate them. I look forward to seeing a patch! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GlobalScript in WebKit
On Mon, Nov 30, 2009 at 8:08 PM, Maciej Stachowiak m...@apple.com wrote: Would it be fair to say the goal for SharedScript is just to share code and data (to reduce memory use of multiple instances of GMail), and not network connections, timers, or other APIs based on async callbacks (assuming those either remain per-Window or are in the SharedWorker)? If so, then it would pretty much completely be handled by sharing of some arbitrary JavaScript object, possibly arranged by SharedWorker. No, we definitely want to share network connections. We'd like users to be able to have an arbitrary number of Gmail windows open without running into the browser connection limit. This is especially relevant for long-lived (comet-like) connections. We also know how many simultaneous connections our servers can handle, so we would like to manage this independently of the number of windows the user has open. On Nov 30, 2009, at 7:13 PM, Michael Davidson wrote: Thanks a lot for sharing your perspective. Hearing it directly is helpful. Would you be willing to share your thoughts with one of the standards mailing lists? One of our concerns is the apparent skepticism of other browser implementors towards this idea. Of course. I believe there have been long threads on whatwg about this already. Ian Hickson stated a belief that SharedWorkers are sufficient, which pretty much killed the conversation. I'm happy to join in again, but I think having two browser implementors on board would go a long way to helping the standards process. The thread has gotten a little broad, so apologies if I miss something. It seems to me there are a few separate questions being discussed: 1) In isolation, is SharedScript a good idea? People seem neutral-to-positive, so I won't spend time addressing this. It's clearly something that would be useful. There are open questions about how it works with Chrome's process model, but I think that's mostly just implementation details. In a world where SharedWorkers never existed, I think people would be jumping on this. Always-shared vs. opportunistically-sometimes-shared seems like a big difference, more than just implementation details. It has a direct impact on how to correctly author content using this mechanism. I'm not sure that this is true. Users can always run multiple browsers with different profiles, or run browsers on different machines. Opportunistic sharing that fails is equivalent to running two separate browser on the same machine. The app has to handle that situation anyway. In a perfect world, we'd like to be able to hint that a toplevel navigation belongs to a set of pages that should share a process. That way if the user navigates to, say, http://mail.google.com, we can tell the browser that we'd like it to be rendered in an existing process if one exists. That would lead to maximal sharing. However, we will always have to handle the case where a user logs in with multiple browsers. Can you think of a scenario where failed opportunistic sharing would be handled differently from the multiple browser case? Are you concerned mainly about users opening a brand new additional GMail window with some already open, or cases of windows created by an original GMail window, like the tear-off chat window? Both. (I ask because windows with a pre-existing relationship like parent/opener could already share code and data if they chose to, without any new browser features. Just pass the functions or objects of your choice to the newly opened window. As mentioned elsewhere on this thread, this isn't a great solution. XHRs and timers, specifically, need to find a new parent window when one window closes. I do have this working for Gmail tearoffs right now, but all windows have to close when the main window closes. Even if this is only part of what you are interested in, it could be an easy way to prototype this programming model and quantify the benefits in terms of speed and memory use. Or if you've tried that experiment already, it would be useful to hear the results. I'm guessing it's not in production GMail since tearing off a chat window is fairly slow and shows a progress bar.) I have code running that drives a tearoff window from the main window and simply closes all tearoffs when the main window closes. The latency improvement is huge. We plan on launching this feature regardless of the outcome of SharedScript. The feature we're discussing would allow two improvements. First, tearoffs wouldn't have to close when the main window closes. Second, new instances of Gmail would be as fast as the new fast tearoffs. There is obviously user demand for multiple full Gmail views. A Googler implemented the multiple inbox lab to satisfy this demand, but many people still use multiple tabs open to Gmail to manage their mail. We could make this work much more smoothly if we could share code, state, and network connections. A third improvement:
Re: [webkit-dev] GlobalScript in WebKit
On Tue, Dec 1, 2009 at 9:15 AM, Michael Davidson m...@google.com wrote: A third improvement: When we adopt the HTML5 notification API for showing users new mail or incoming chat notifications we will only show one notification regardless of the number of Gmail tabs that are open. Today each window would have to show a notification. That one just occurred to me, I'm sure we can come up with others. Michael FWIW, we've been pushing developers to use SharedWorkers to manage their notifications for exactly this reason. It's fairly trivial to do so, since notifications are fundamentally an async API anyway. But agreed that SharedScript would also work for this. -atw - Maciej I sense that there's some pushback due to a Google property requesting a feature that Google engineers are trying to get into the browser, but I think that Gmail is emblematic of all large web apps. Shared workers have their place, but that place is not sharing the UI code for large apps. I saw a comment that forcing multiple windows of one application into the same process is undesirable. I disagree. Gmail is not a CPU-bound application. We believe that the savings of having one JS heap, one request queue, one data store, etc. would outweigh the benefits of process isolation. 3) Should SharedScript be added to WebKit? I'm not a WebKit developer, so I'm not as qualified to comment. However, I believe that SharedScript is a feature that many apps would use. We tried to come up with a representative set of examples in the spec. We're happy to come up with more. I don't believe that SharedWorkers will solve those scenarios. I doubt that developers inside or outside of Google will move to a totally async programming model. Sorry that this initial mail is also a little scattered. I'll try to stay on top of the conversation as it progresses, and will hopefully be able to provide a perspective from the trenches of web development. Michael On Mon, Nov 30, 2009 at 6:16 PM, Drew Wilson atwil...@google.com wrote: Following up, I think this highlights the distinct set of use cases that shared workers and shared script address: SharedWorkers are a great platform for when you have a single database that is shared across multiple instances of your web app, and you want to coordinate updates to that database. I can imagine sharing a single connection to the server, etc via SharedWorkers. SharedScripts are a good platform for when you want to share data/code (for example, the immense body of Javascript used to implement the Gmail UI) across multiple windows. I can't speak to whether passing a hidden iframe between windows as was suggested in the other thread would address this use case sufficiently. -atw On Mon, Nov 30, 2009 at 6:11 PM, Drew Wilson atwil...@google.comwrote: I believe that the offline gmail team uses the Gears flavor of shared workers and is planning to migrate to the HTML5 version once DB access is supported from within worker context in shipping browsers. So I guess that Gmail would be a candidate app that has asked for both. -atw On Mon, Nov 30, 2009 at 6:08 PM, Maciej Stachowiak m...@apple.comwrote: On Nov 30, 2009, at 3:43 PM, Dmitry Titov wrote: I don't think it's correct to say that SharedWorkers are not useful and we need a SharedScript instead. They are different things and can address different use cases. For example, SharedWorker is great to make sure there is only one 'app instance' running - exactly because it is shared inter-process, it can be used as a inter-process synchronization primitive to control how many app instances are opened. SharedScript is a container for data and code shared between pages that comprise a web application and normally run in the same process. As in native apps, whether or not multiple instances of the app can run at the same time depends on the author of the app, and can be done either way. Are there any Web apps at Google or elsewhere currently using SharedWorker? Would any of them still use it if they could switch to SharedScript? Has any app team specifically requested support for *both* SharedWorker *and* SharedScript? (Serious questions, since the justification for SharedScript is largely based on Web developer feedback.) Note: if SharedScript was really globally shared it could be used to implement shared workers - simply have the SharedScript manage the per-app Workers. 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GlobalScript in WebKit
One question about version conflicts and how they might get worse; sorry if it's already been addressed. What happens if a user has an old version of an application like Gmail open and then tries to open a new window to the app, after developers have added new features? I presume the new window is stuck talking to the old version of the SharedScript? Version conflicts are obviously already possible (without SharedScripts) if an old application opens a new window and tries to talk to it. Today, though, it's at least mostly safe to have a week-old copy of an app open and then load a separate, newer version in a different window. (I'm doing that right now with Gmail.) With SharedScripts in place, it seems like either (1) the new version of the app would have to detect the old SharedScript and deal with it or (2) the user would continue to see errors until he reloaded all the open app windows to get the new version. And would reloading be sufficient, or would he have to close all the app windows to make the SharedScript go away? Basically, SharedScripts make multiple windows more dependent on each other. There's a lot of benefits to that, though it could also make problems like version conflicts more common. Have there been any thoughts on ways to address this, or should it be left to web developers? (I didn't see anything in the design doc.) Charlie On Tue, Dec 1, 2009 at 9:33 AM, Drew Wilson atwil...@google.com wrote: On Tue, Dec 1, 2009 at 9:15 AM, Michael Davidson m...@google.com wrote: A third improvement: When we adopt the HTML5 notification API for showing users new mail or incoming chat notifications we will only show one notification regardless of the number of Gmail tabs that are open. Today each window would have to show a notification. That one just occurred to me, I'm sure we can come up with others. Michael FWIW, we've been pushing developers to use SharedWorkers to manage their notifications for exactly this reason. It's fairly trivial to do so, since notifications are fundamentally an async API anyway. But agreed that SharedScript would also work for this. -atw - Maciej I sense that there's some pushback due to a Google property requesting a feature that Google engineers are trying to get into the browser, but I think that Gmail is emblematic of all large web apps. Shared workers have their place, but that place is not sharing the UI code for large apps. I saw a comment that forcing multiple windows of one application into the same process is undesirable. I disagree. Gmail is not a CPU-bound application. We believe that the savings of having one JS heap, one request queue, one data store, etc. would outweigh the benefits of process isolation. 3) Should SharedScript be added to WebKit? I'm not a WebKit developer, so I'm not as qualified to comment. However, I believe that SharedScript is a feature that many apps would use. We tried to come up with a representative set of examples in the spec. We're happy to come up with more. I don't believe that SharedWorkers will solve those scenarios. I doubt that developers inside or outside of Google will move to a totally async programming model. Sorry that this initial mail is also a little scattered. I'll try to stay on top of the conversation as it progresses, and will hopefully be able to provide a perspective from the trenches of web development. Michael On Mon, Nov 30, 2009 at 6:16 PM, Drew Wilson atwil...@google.comwrote: Following up, I think this highlights the distinct set of use cases that shared workers and shared script address: SharedWorkers are a great platform for when you have a single database that is shared across multiple instances of your web app, and you want to coordinate updates to that database. I can imagine sharing a single connection to the server, etc via SharedWorkers. SharedScripts are a good platform for when you want to share data/code (for example, the immense body of Javascript used to implement the Gmail UI) across multiple windows. I can't speak to whether passing a hidden iframe between windows as was suggested in the other thread would address this use case sufficiently. -atw On Mon, Nov 30, 2009 at 6:11 PM, Drew Wilson atwil...@google.comwrote: I believe that the offline gmail team uses the Gears flavor of shared workers and is planning to migrate to the HTML5 version once DB access is supported from within worker context in shipping browsers. So I guess that Gmail would be a candidate app that has asked for both. -atw On Mon, Nov 30, 2009 at 6:08 PM, Maciej Stachowiak m...@apple.comwrote: On Nov 30, 2009, at 3:43 PM, Dmitry Titov wrote: I don't think it's correct to say that SharedWorkers are not useful and we need a SharedScript instead. They are different things and can address different use cases. For example, SharedWorker is great to make sure there is only one 'app instance' running - exactly
Re: [webkit-dev] GlobalScript in WebKit
Fair enough-- it sounds like SharedScript could improve things in that sense. Though shutting down the app might now mean hunting down and closing all the tabs that have it open, if not restarting the browser. (To be honest, I'm not sure how many copies of Gmail I have open right now, but I tend to have a lot of windows and tabs.) :) Charlie On Tue, Dec 1, 2009 at 10:44 AM, Michael Davidson m...@google.com wrote: Truthfully, the current situation with Gmail tearoffs is way, way worse in terms of versioning. We use the Closure Compiler for our JS, which means that a tearoff window opened from the main window might not be able to get necessary data from the main window! (Even for slow tearoffs we get some data from the main window.) Gmail (and I'd imagine most sophisticated apps) has a notion of version that the client understands. The situation with SharedScript would be analogous to how Chrome auto-updates - you'd just have to shut the app down to get the new version. We plan on mitigating this by using AppCache to preload new versions of the script so that the reload is fast, but overall I don't think this is a big problem. Michael On Tue, Dec 1, 2009 at 10:41 AM, Charles Reis cr...@chromium.org wrote: One question about version conflicts and how they might get worse; sorry if it's already been addressed. What happens if a user has an old version of an application like Gmail open and then tries to open a new window to the app, after developers have added new features? I presume the new window is stuck talking to the old version of the SharedScript? Version conflicts are obviously already possible (without SharedScripts) if an old application opens a new window and tries to talk to it. Today, though, it's at least mostly safe to have a week-old copy of an app open and then load a separate, newer version in a different window. (I'm doing that right now with Gmail.) With SharedScripts in place, it seems like either (1) the new version of the app would have to detect the old SharedScript and deal with it or (2) the user would continue to see errors until he reloaded all the open app windows to get the new version. And would reloading be sufficient, or would he have to close all the app windows to make the SharedScript go away? Basically, SharedScripts make multiple windows more dependent on each other. There's a lot of benefits to that, though it could also make problems like version conflicts more common. Have there been any thoughts on ways to address this, or should it be left to web developers? (I didn't see anything in the design doc.) Charlie On Tue, Dec 1, 2009 at 9:33 AM, Drew Wilson atwil...@google.com wrote: On Tue, Dec 1, 2009 at 9:15 AM, Michael Davidson m...@google.com wrote: A third improvement: When we adopt the HTML5 notification API for showing users new mail or incoming chat notifications we will only show one notification regardless of the number of Gmail tabs that are open. Today each window would have to show a notification. That one just occurred to me, I'm sure we can come up with others. Michael FWIW, we've been pushing developers to use SharedWorkers to manage their notifications for exactly this reason. It's fairly trivial to do so, since notifications are fundamentally an async API anyway. But agreed that SharedScript would also work for this. -atw - Maciej I sense that there's some pushback due to a Google property requesting a feature that Google engineers are trying to get into the browser, but I think that Gmail is emblematic of all large web apps. Shared workers have their place, but that place is not sharing the UI code for large apps. I saw a comment that forcing multiple windows of one application into the same process is undesirable. I disagree. Gmail is not a CPU-bound application. We believe that the savings of having one JS heap, one request queue, one data store, etc. would outweigh the benefits of process isolation. 3) Should SharedScript be added to WebKit? I'm not a WebKit developer, so I'm not as qualified to comment. However, I believe that SharedScript is a feature that many apps would use. We tried to come up with a representative set of examples in the spec. We're happy to come up with more. I don't believe that SharedWorkers will solve those scenarios. I doubt that developers inside or outside of Google will move to a totally async programming model. Sorry that this initial mail is also a little scattered. I'll try to stay on top of the conversation as it progresses, and will hopefully be able to provide a perspective from the trenches of web development. Michael On Mon, Nov 30, 2009 at 6:16 PM, Drew Wilson atwil...@google.comwrote: Following up, I think this highlights the distinct set of use cases that shared workers and shared script address: SharedWorkers are a great platform for when you have a single database that is
Re: [webkit-dev] trac.webkit.org links via Google.com
Robots.txt can exclude most of the trac site, and then include the sitemap.xml. This way you block most of the junk and only give permission to the important file. All major search engine support sitemap.xml, and those that don't will be blocked by robots.txt. A script could generate sitemap.xml from a local svn checkout of trunk. It will produce one url for each source file (frequency=daily) and one url for every revision (frequency=year). That will cover most of the search requirements. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Adding read-only javascript properties via JavaScriptCore
Hi, I'm using the JavaScriptCore (Mac) API to add some properties into the javascript environment and would like to make sure that these properties are read only from the javascript side. From the looks of the API, I thought adding the properties with calls like this would do the trick: JSObjectSetProperty(ctx, globalObject, propertyName, propertyValue, kJSPropertyAttributeDontDelete | kJSPropertyAttributeReadOnly, NULL); The property gets added without any troubles but in javascript (and the Web Inspector) I can modify and delete the properties that I've added. Am I I missing something or just reading the docs wrong? Thanks. --Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding read-only javascript properties via JavaScriptCore
This email seems like it would be better directed to webkit-help. In general, that's not possible to create read-only properties in JavaScript because the environment is so malleable. Adam On Tue, Dec 1, 2009 at 11:10 AM, Ryan Grimm gr...@xqdev.com wrote: Hi, I'm using the JavaScriptCore (Mac) API to add some properties into the javascript environment and would like to make sure that these properties are read only from the javascript side. From the looks of the API, I thought adding the properties with calls like this would do the trick: JSObjectSetProperty(ctx, globalObject, propertyName, propertyValue, kJSPropertyAttributeDontDelete | kJSPropertyAttributeReadOnly, NULL); The property gets added without any troubles but in javascript (and the Web Inspector) I can modify and delete the properties that I've added. Am I I missing something or just reading the docs wrong? Thanks. --Ryan ___ 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 render tree dump
I actually have a giant set of changes that need to be made to the render tree dumping... many of which are outlined in comments. The problem is it causes all the test results to have to be updated. Right now many silly and incorrect things are being dumped right now just for backwards compatibility. It's not ideal. dave On Dec 1, 2009, at 1:14 PM, Darin Adler wrote: On Nov 30, 2009, at 6:29 PM, pundarik rajkhowa wrote: Thanks for the info. I am aware of the pixel test, but for my purpose that cant be used, since text-based comparision is preferred. Regarding the style attributes, the webkit dump actually contains a few of them like color, bgcolor, borderstyle etc. Is there any specific reason for that ? Also if I dump other attributes like font-weight, text-decoration etc using the style() api of the RenderObject, will that help catching bugs specific to these attributes ? It would be OK to dump more. There are two difficulties: 1) If we add more to what is dumped, the additional information may create even more noise in existing test results, repeated things that make the salient details hard to find. The original choice of what to dump was based on a tradeoff in a hope to make the dumps readable. 2) If we add more to what is dumped, that patch has to update the results of thousands of tests on multiple platforms. Sometimes you can come up with a rule to decide when to dump that can mitigate both problems (1) and (2), for example, dumping only when values are unusual. -- 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] Adding read-only javascript properties via JavaScriptCore
I'm sorry about that, I intended to send it to webkit-help but typed in the wrong address. --Ryan On Dec 1, 2009, at 11:15 AM, Adam Barth wrote: This email seems like it would be better directed to webkit-help. In general, that's not possible to create read-only properties in JavaScript because the environment is so malleable. Adam On Tue, Dec 1, 2009 at 11:10 AM, Ryan Grimm gr...@xqdev.com wrote: Hi, I'm using the JavaScriptCore (Mac) API to add some properties into the javascript environment and would like to make sure that these properties are read only from the javascript side. From the looks of the API, I thought adding the properties with calls like this would do the trick: JSObjectSetProperty(ctx, globalObject, propertyName, propertyValue, kJSPropertyAttributeDontDelete | kJSPropertyAttributeReadOnly, NULL); The property gets added without any troubles but in javascript (and the Web Inspector) I can modify and delete the properties that I've added. Am I I missing something or just reading the docs wrong? Thanks. --Ryan ___ 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] trac.webkit.org links via Google.com
On 2009-12-01, at 11:04, Yaar Schnitman wrote:
Robots.txt can exclude most of the trac site, and then include the
sitemap.xml. This way you block most of the junk and only give permission to
the important file. All major search engine support sitemap.xml, and those
that don't will be blocked by robots.txt.
A script could generate sitemap.xml from a local svn checkout of trunk. It
will produce one url for each source file (frequency=daily) and one url for
every revision (frequency=year). That will cover most of the search
requirements.
Forgive me, but this doesn't seem to address the issues that I raised in my
previous message.
To reiterate: We need to allow only an explicit set of URLs to be crawled.
Sitemaps do not provide this ability. They expose information about set of
URLs to a crawler, they do not limit the set of URLs that it can crawl. A
robots.txt file does provide the ability to limit the set of URLs that can be
crawled.
However, the semantics of robots.txt seem to make it incredibly unwieldy to
expose only the content of interest, if it is possible at all. For instance,
to expose http://trac.webkit.org/changeset/#{revision} while preventing
http://trac.webkit.org/changeset/#{revision}/#{path} or
http://trac.webkit.org/changeset/#{revision}?format=zipnew=#{revision} from
being crawled. Another example would be exposing
http://trac.webkit.org/browser/#{path} while preventing
http://trac.webkit.org/browser/#{path}?rev=#{revision} from being crawled.
Is there something that I'm missing?
- Mark
smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharableScriptContext [was: GlobalScript in WebKit]
A worker context without the thread is close to what we're after, except for
the bit about how it doesn't do network stuff or timeouts. Fundamentally
what we need is, a place for centralizing network access and significant
amounts of application state, and sharing large amounts of code, that is
independent of any single window, and can manipulate the DOM of an arbitrary
number of application windows that are either created by code in this
independent context, or created by the user through navigation. We'd like to
be able to create this context from an extension, so if a user wishes to
have instant access to their gmail, or facebook, or whatever, they could
choose to install an extension that would create this context when the
browser starts.
Shared workers fundamentally don't do the trick because (a) most of the code
in the application has nothing to do with accessing the server, and
everything to do with presenting the UI, so shared workers don't help with
sharing the code among multiple windows, and (b) we want the UI to be
immediately responsive, which means not waiting for a worker thread to get
back to the UI thread with data, so we'd be caching the data both in the UI
context and in the worker thread context, in which case we might as well
just go to the server.
When using a named window, there are interesting race conditions (unless you
do something like the appcache suggestion to ensure the windows are in the
same process) when one is restoring the browser state on startup. The
significant challenge for the app developer is to deal with, when the named
window closes, in-flight non-idempotent XHRs and registered timeouts that
ought to be independent of any window, but that are tied to the named
window. Timeouts are easier to deal with (centralized timer manager that
remembers the deadline for each and reschedules in the context of the new
named window). Being able to reparent an XHR in flight would make handling
the transition easier
a
On Mon, Nov 30, 2009 at 10:24 PM, Oliver Hunt oli...@apple.com wrote:
On Nov 30, 2009, at 10:12 PM, Dmitry Titov wrote:
At first look, this would solve same use cases as SharedScript. The
difference is that it has to be passed to participating windows
explicitly. Summing up, just for reference:
var mySharedScriptContext = new SharedScriptContext(foo.js);
mySharedScriptContext.onload = ...;
later:
var win = window.open(...);
win.functionThatTakesSharedScriptContext(mySharedScriptContext);
alternatively, later:
var win = window.getWindowByName(foo); // does not create a window if
there is no foo, searches in same process
if (win)
win.functionThatTakesSharedScriptContext(mySharedScriptContext);
and, possibly: add a list (regexp?) to App Cache manifest to describe the
set of URLs loaded into the same process to make them able to find each
other without relying on window.open().
The idea behind SharedScriptContext+getWindowByName was that it would be
possible to do (in your new window)
if (sharedWin = getWindowByName(OriginWindow))
sharedContext = sharedWin.sharedContext;
else {
name = OriginWindow;
sharedContext = new SharedScriptContext(foo.js);
}
At least that was my understanding.
What is your application cache suggestion attempting to do? The whole
point of getWindowByName is that it doesn't need window.open
All that said, Darin, Maciej and I were discussing this on IRC earlier and
it would seem that simply adding getWindowByName (or some such) would gain a
very large amount of the behaviour desired in the {Shared,
Global}Script[Context] concept.
--Oliver
Dmitry
On Mon, Nov 30, 2009 at 9:07 PM, Darin Fisher da...@chromium.org wrote:
On Mon, Nov 30, 2009 at 8:52 PM, Oliver Hunt oli...@apple.com wrote:
On Nov 30, 2009, at 8:31 PM, Darin Fisher wrote:
On Mon, Nov 30, 2009 at 7:55 PM, Maciej Stachowiak m...@apple.comwrote:
On Nov 30, 2009, at 6:16 PM, Drew Wilson wrote:
Following up, I think this highlights the distinct set of use cases that
shared workers and shared script address:
SharedWorkers are a great platform for when you have a single database
that is shared across multiple instances of your web app, and you want to
coordinate updates to that database. I can imagine sharing a single
connection to the server, etc via SharedWorkers.
SharedScripts are a good platform for when you want to share data/code
(for example, the immense body of Javascript used to implement the Gmail
UI)
across multiple windows. I can't speak to whether passing a hidden iframe
between windows as was suggested in the other thread would address this use
case sufficiently.
Would it be fair to say the goal for SharedScript is just to share code
and data (to reduce memory use of multiple instances of GMail), and not
network connections, timers, or other APIs based on async callbacks
(assuming those either remain per-Window or are in the SharedWorker)? If
so,
then it would pretty much
Re: [webkit-dev] SharableScriptContext [was: GlobalScript in WebKit]
On Tue, Dec 1, 2009 at 12:11 AM, Oliver Hunt oli...@apple.com wrote: On Nov 30, 2009, at 11:47 PM, Adam de Boor wrote: A worker context without the thread is close to what we're after, except for the bit about how it doesn't do network stuff or timeouts. Errr, what? Workers can do networking, timeouts -- xhr, setTimeout, setInterval, etc is available to them so i'm not sure what you mean by that? I was referring back to an earlier message from Maciej: Would it be fair to say the goal for SharedScript is just to share code and data (to reduce memory use of multiple instances of GMail), and not network connections, timers, or other APIs based on async callbacks (assuming those either remain per-Window or are in the SharedWorker)? As for the DOM -- the only reason for a Worker not having access to the DOM is because the only means for communication is postMessage which doesn't allow pass by reference (and most/all DOM implementations assume single threaded access). Assuming this magical object existed you would be better off thinking of it as being an iframe without a document and with a lifetime unbounded by its parent. This magical object is what SharedScript is speced to be. Fundamentally what we need is, a place for centralizing network access and significant amounts of application state, and sharing large amounts of code, that is independent of any single window, and can manipulate the DOM of an arbitrary number of application windows that are either created by code in this independent context, or created by the user through navigation. We'd like to be able to create this context from an extension, so if a user wishes to have instant access to their gmail, or facebook, or whatever, they could choose to install an extension that would create this context when the browser starts. I'm not sure how this would work -- as far as I am aware extensions in chrome make use of isolated worlds, which should prevent an extension from creating an object that can be shared with any normal webpage, and of course the extension would not be in the same origin as the page you're hoping for so wouldn't be able to share anything anyway. This would be an addition to extensions. That said your whole extension for preloading concept seems like it could be mostly duplicated by using the application cache -- you'd still get hit with compilation time (theoretically once in this model) but compared with load time compilation is inconsequential. The application cache as specified is simply a way of storing resources as a unit, with background update. One could leverage it to store other things about the application (e.g. freeze-drying the app most of the way through startup so it can be started again faster), but it's got nothing to do with having the application headless-but-alive, with data downloaded from the server, able to generate notifications, if the user has requested them, etc. Shared workers fundamentally don't do the trick because (a) most of the code in the application has nothing to do with accessing the server, and everything to do with presenting the UI, so shared workers don't help with sharing the code among multiple windows, and (b) we want the UI to be immediately responsive, which means not waiting for a worker thread to get back to the UI thread with data, so we'd be caching the data both in the UI context and in the worker thread context, in which case we might as well just go to the server. Errr, if asking a worker for data is taking as long as a server request there's a bug... I'm really not sure what you're saying here. It's less a question of speed than it is of control flow. What's the advantage of requiring applications to structure themselves so that all accesses to data are asynchronous? If you look at applications that access a database, for example, they will frequently make local caches of read-only data, but they don't then put those caches in another thread that requires them to break their event handling into stages. What would be the point? Given that there's no burden on the app in sending a request to the server (the browser effectively does it in the background), there's no reason to put it in a worker thread. a When using a named window, there are interesting race conditions (unless you do something like the appcache suggestion to ensure the windows are in the same process) when one is restoring the browser state on startup. The significant challenge for the app developer is to deal with, when the named window closes, in-flight non-idempotent XHRs and registered timeouts that ought to be independent of any window, but that are tied to the named window. Timeouts are easier to deal with (centralized timer manager that remembers the deadline for each and reschedules in the context of the new named window). Being able to reparent an XHR in flight would make handling the transition easier From what
Re: [webkit-dev] GlobalScript in WebKit
On Tue, 1 Dec 2009, Michael Davidson wrote: On Mon, Nov 30, 2009 at 8:08 PM, Maciej Stachowiak m...@apple.com wrote: Would it be fair to say the goal for SharedScript is just to share code and data (to reduce memory use of multiple instances of GMail), and not network connections, timers, or other APIs based on async callbacks (assuming those either remain per-Window or are in the SharedWorker)? If so, then it would pretty much completely be handled by sharing of some arbitrary JavaScript object, possibly arranged by SharedWorker. No, we definitely want to share network connections. We'd like users to be able to have an arbitrary number of Gmail windows open without running into the browser connection limit. SharedScript doesn't give you that. Only a singleton mechanism can give you that. Always-shared vs. opportunistically-sometimes-shared seems like a big difference, more than just implementation details. It has a direct impact on how to correctly author content using this mechanism. I'm not sure that this is true. Users can always run multiple browsers with different profiles, or run browsers on different machines. Using different machines, different browsers, or different profiles has some pretty major differences with using different tabs (processes) in Chrome: only in the latter would one common database, storage, and cookie infrastructure be shared, only in the latter would the HTTP per-origin connection limit be shared, only in the latter would application caches and HTTP caches be shared, etc. In a perfect world, we'd like to be able to hint that a toplevel navigation belongs to a set of pages that should share a process. That way if the user navigates to, say, http://mail.google.com, we can tell the browser that we'd like it to be rendered in an existing process if one exists. That would lead to maximal sharing. Since iframes have to share a process even across origins, and since window.open() from an iframe has to share the process of the opener, it is trivial to engineer a situation where it's not possible to share the process. This kind of situation would commonly arise with pages like iGoogle that embed a GMail gadget. (I ask because windows with a pre-existing relationship like parent/opener could already share code and data if they chose to, without any new browser features. Just pass the functions or objects of your choice to the newly opened window. As mentioned elsewhere on this thread, this isn't a great solution. XHRs and timers, specifically, need to find a new parent window when one window closes. I do have this working for Gmail tearoffs right now, but all windows have to close when the main window closes. It seems that you could just create an iframe instead of the SharedScript, and pass it around onunload. A third improvement: When we adopt the HTML5 notification API for showing users new mail or incoming chat notifications we will only show one notification regardless of the number of Gmail tabs that are open. You can't do that with SharedScript, since it's not guaranteed to be unique across the browser. However, SharedScript misleads people into thinking that they can do that, which is one reason that I am skeptical that it is a good idea. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GlobalScript in WebKit
On Tue, Dec 1, 2009 at 11:51 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 1 Dec 2009, Michael Davidson wrote: No, we definitely want to share network connections. We'd like users to be able to have an arbitrary number of Gmail windows open without running into the browser connection limit. SharedScript doesn't give you that. Only a singleton mechanism can give you that. Assuming that the same-process hinting works, it will give us that. At the very least, it will vastly improve the situation we have today. The iGoogle gadget that you mention later would not use SharedScript, FWIW. The mechinism that it uses to get data from Gmail is entirely different. I agree that anything that lives in an iframe is going to cause problems for SharedScript, but Gmail (like many webapps where having the URL exposed to the user is very important) doesn't allow itself to be in an iframe. As mentioned elsewhere on this thread, this isn't a great solution. XHRs and timers, specifically, need to find a new parent window when one window closes. I do have this working for Gmail tearoffs right now, but all windows have to close when the main window closes. It seems that you could just create an iframe instead of the SharedScript, and pass it around onunload. Can an iframe live independently of its creating document? I can do some experiments with existing browsers, but I would be surprised if a reference to an iframe were enough to keep it alive when its containing document is closed. You can't do that with SharedScript, since it's not guaranteed to be unique across the browser. However, SharedScript misleads people into thinking that they can do that, which is one reason that I am skeptical that it is a good idea. So this might not have been the best-considered example. The ability to share network connections is a better one, where failure to share isn't catastrophic, but success has benefits. The goal of the proposal is to make sharing as easy as possible and to allow apps to reduce the amount of resources they use. The goal is not to mislead people into thinking that SharedScript is bulletproof sharing, which is why the spec says that sharing might fail. I believe, from talking to web app developers, that simple sharing that might fail is a desirable feature. It is true that if you absolutely need to guarantee sharing that shared workers are a better solution, but for our app we don't need that guarantee and find workers unsuitable for UI code for reasons stated earlier in the thread. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GlobalScript in WebKit
On Tue, 1 Dec 2009, Michael Davidson wrote: On Tue, Dec 1, 2009 at 11:51 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 1 Dec 2009, Michael Davidson wrote: No, we definitely want to share network connections. We'd like users to be able to have an arbitrary number of Gmail windows open without running into the browser connection limit. SharedScript doesn't give you that. Only a singleton mechanism can give you that. Assuming that the same-process hinting works, it will give us that. The process hinting is not a guarantee. It is trivial to come up with situations where different documents from the same origin are required to end up in different processes. Furthermore, as a user, I would personally much rather every GMail instance I open end up in a different process, for the same reason that I'd like GMail and Google Calendar in different instances, and Google Calendar and Google Search in different processes, and Search and pages I get to from Search in different processes. At the very least, it will vastly improve the situation we have today. Either you definitely want to share network connections, in which case it doesn't give you what you want, or you don't need to share network connections, in which case it seems no better than an iframe. The iGoogle gadget that you mention later would not use SharedScript, FWIW. Sure, but if it opens a true GMail window, that GMail window would have to end up in the same process as the parent (so that the opener can be accessed), which means it wouldn't be the same process as other GMail tabs. It doesn't have to be an iGoogle gadget; any page that window.open()s GMail would be in this situation as far as I can tell. I agree that anything that lives in an iframe is going to cause problems for SharedScript, but Gmail (like many webapps where having the URL exposed to the user is very important) doesn't allow itself to be in an iframe. It prevents it using script, which is too late since the process selection happens long before the script runs. It seems that you could just create an iframe instead of the SharedScript, and pass it around onunload. Can an iframe live independently of its creating document? Per spec, yes, so long as it is owned by a living document it'll keep existing. It should even work in browsers so long as you actually keep the iframe grafted to an existing Window's Document -- hence the pass it around onunload to keep it alive. The goal is not to mislead people into thinking that SharedScript is bulletproof sharing, which is why the spec says that sharing might fail. Yes, but people will think that's what it does, regardless of what it does, because in most testing that's what it will do. It's like the localStorage debacle -- we have to offer consistency guarantees because people will assume them regardless of what the spec says. Anyway, I'm not trying to discourage experimentation here; I just wanted to make it clear that SharedScript doesn't solve the shared networking problem, because it can never be guarenteed to be a singleton -- indeed, from the user's perspective, it would be undesireable for it to be possible to make the browser always put all tabs from one origin into the same process even if it was possible. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding read-only javascript properties via JavaScriptCore
Sounds like a bug. Geoff On Dec 1, 2009, at 11:10 AM, Ryan Grimm wrote: Hi, I'm using the JavaScriptCore (Mac) API to add some properties into the javascript environment and would like to make sure that these properties are read only from the javascript side. From the looks of the API, I thought adding the properties with calls like this would do the trick: JSObjectSetProperty(ctx, globalObject, propertyName, propertyValue, kJSPropertyAttributeDontDelete | kJSPropertyAttributeReadOnly, NULL); The property gets added without any troubles but in javascript (and the Web Inspector) I can modify and delete the properties that I've added. Am I I missing something or just reading the docs wrong? Thanks. --Ryan ___ 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] trac.webkit.org links via Google.com
The urls in sitemap.xml are not patterns - there are exact urls the search
engine will retrieve.
So, you would blacklist most urls with blanket rules in robots.txt and
whitelist explicit urls in sitemap.xml. e.g. in robots.txt, blacklist
/changeset/*, and in sitemap.xml whitelist all
http://trac.webkit.org/changeset/1http://trac.webkit.org/changeset/#%7Brevision%7D
to http://trac.webkit.org/changeset/6 (It's going to be a big file
alright).
On Tue, Dec 1, 2009 at 11:33 AM, Mark Rowe mr...@apple.com wrote:
On 2009-12-01, at 11:04, Yaar Schnitman wrote:
Robots.txt can exclude most of the trac site, and then include the
sitemap.xml. This way you block most of the junk and only give permission to
the important file. All major search engine support sitemap.xml, and those
that don't will be blocked by robots.txt.
A script could generate sitemap.xml from a local svn checkout of trunk. It
will produce one url for each source file (frequency=daily) and one url for
every revision (frequency=year). That will cover most of the search
requirements.
Forgive me, but this doesn't seem to address the issues that I raised in my
previous message.
To reiterate: We need to allow only an explicit set of URLs to be crawled.
Sitemaps *do not* provide this ability. They expose information about set
of URLs to a crawler, they do not limit the set of URLs that it can crawl.
A robots.txt file *does* provide the ability to limit the set of URLs
that can be crawled.
However, the semantics of robots.txt seem to make it incredibly unwieldy to
expose *only *the content of interest, if it is possible at all. For
instance, to expose
http://trac.webkit.org/changeset/#{revision}http://trac.webkit.org/changeset/#%7Brevision%7D
while preventing http://trac.webkit.org/changeset/#{revision}/#{path} or
http://trac.webkit.org/changeset/#{revision}?http://trac.webkit.org/changeset/#%7Brevision%7D?format=zipnew=#{revision}
from
being crawled. Another example would be exposing
http://trac.webkit.org/browser/#{path}http://trac.webkit.org/browser/#%7Bpath%7D
while preventing http://trac.webkit.org/browser/#{path}?rev=#{revision}
from being crawled.
Is there something that I'm missing?
- Mark
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] namespace indent
A common false positive in the style-queue is as follows: Code inside a namespace should not be indented. [whitespace/indent] [4] That's because the namespace indent rule is fairly new and its hard to fix without touching the whole file. I don't think the style-queue should be spamming bugs with non-actionable information. There seem to be a few choices: 1) Disable this warning because it's not helpful at the moment. 2) Change our code to comply with this style rule (e.g., as we touch files, fix them so that the warning doesn't occur). 3) Change our style guide to match our code. Personally, I'm in favor of (2) because it seems silly to have a rule in our style guide with which we never plan to actually comply. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GlobalScript in WebKit
Just to provide some history... An intrinsic aspect of the SharedScript proposal is that scripting across the page / sharedScript boundary should be very fast. When coming up with the original proposal, we were careful to not require singleton semantics that would work against that goal (by requiring ipc proxy'ing and thread synchronization). A common context for all instances of a page was intentionally not a goal since to make that gaurantee would be very much at odds with the performance goal. We tried to strike that balance between the scope of sharing and the promise of being performant by saying all pages within a unit of related browsing contexts are guaranteed to shared the same SharedContexts. In our proposal, the scope of shared is permitted to be wider, but is not required to be wider. A secondary concern is co-locating top-level pages to widen the scope of sharing beyond just the unit of related browsing contexts. We've hand waved at hints that could help the browser accomplish that. On Tue, Dec 1, 2009 at 12:20 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 1 Dec 2009, Michael Davidson wrote: On Tue, Dec 1, 2009 at 11:51 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 1 Dec 2009, Michael Davidson wrote: No, we definitely want to share network connections. We'd like users to be able to have an arbitrary number of Gmail windows open without running into the browser connection limit. SharedScript doesn't give you that. Only a singleton mechanism can give you that. Assuming that the same-process hinting works, it will give us that. The process hinting is not a guarantee. It is trivial to come up with situations where different documents from the same origin are required to end up in different processes. Furthermore, as a user, I would personally much rather every GMail instance I open end up in a different process, for the same reason that I'd like GMail and Google Calendar in different instances, and Google Calendar and Google Search in different processes, and Search and pages I get to from Search in different processes. At the very least, it will vastly improve the situation we have today. Either you definitely want to share network connections, in which case it doesn't give you what you want, or you don't need to share network connections, in which case it seems no better than an iframe. The iGoogle gadget that you mention later would not use SharedScript, FWIW. Sure, but if it opens a true GMail window, that GMail window would have to end up in the same process as the parent (so that the opener can be accessed), which means it wouldn't be the same process as other GMail tabs. It doesn't have to be an iGoogle gadget; any page that window.open()s GMail would be in this situation as far as I can tell. I agree that anything that lives in an iframe is going to cause problems for SharedScript, but Gmail (like many webapps where having the URL exposed to the user is very important) doesn't allow itself to be in an iframe. It prevents it using script, which is too late since the process selection happens long before the script runs. It seems that you could just create an iframe instead of the SharedScript, and pass it around onunload. Can an iframe live independently of its creating document? Per spec, yes, so long as it is owned by a living document it'll keep existing. It should even work in browsers so long as you actually keep the iframe grafted to an existing Window's Document -- hence the pass it around onunload to keep it alive. The goal is not to mislead people into thinking that SharedScript is bulletproof sharing, which is why the spec says that sharing might fail. Yes, but people will think that's what it does, regardless of what it does, because in most testing that's what it will do. It's like the localStorage debacle -- we have to offer consistency guarantees because people will assume them regardless of what the spec says. Anyway, I'm not trying to discourage experimentation here; I just wanted to make it clear that SharedScript doesn't solve the shared networking problem, because it can never be guarenteed to be a singleton -- indeed, from the user's perspective, it would be undesireable for it to be possible to make the browser always put all tabs from one origin into the same process even if it was possible. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ 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] namespace indent
(2). On Dec 1, 2009, at 2:42 PM, Adam Barth wrote: A common false positive in the style-queue is as follows: Code inside a namespace should not be indented. [whitespace/indent] [4] That's because the namespace indent rule is fairly new and its hard to fix without touching the whole file. I don't think the style-queue should be spamming bugs with non-actionable information. There seem to be a few choices: 1) Disable this warning because it's not helpful at the moment. 2) Change our code to comply with this style rule (e.g., as we touch files, fix them so that the warning doesn't occur). 3) Change our style guide to match our code. Personally, I'm in favor of (2) because it seems silly to have a rule in our style guide with which we never plan to actually comply. Thoughts? Adam ___ 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] namespace indent
For (2), are we sure the relevant diff tools can isolate the real changes to those files amid mass indentation? Most if not all can, but I don't know about the automatic diffs that may be part of the webkit build/release/publish process. Not that this is a deal-breaker, but I wanted to bring it up. On Dec 1, 2009, at 12:52 PM, David Hyatt wrote: (2). On Dec 1, 2009, at 2:42 PM, Adam Barth wrote: A common false positive in the style-queue is as follows: Code inside a namespace should not be indented. [whitespace/indent] [4] That's because the namespace indent rule is fairly new and its hard to fix without touching the whole file. I don't think the style-queue should be spamming bugs with non-actionable information. There seem to be a few choices: 1) Disable this warning because it's not helpful at the moment. 2) Change our code to comply with this style rule (e.g., as we touch files, fix them so that the warning doesn't occur). 3) Change our style guide to match our code. Personally, I'm in favor of (2) because it seems silly to have a rule in our style guide with which we never plan to actually comply. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] namespace indent
The pretty diff on Bugzilla knows how to show you what's changed on a given line (e.g., whitespace). Adam On Tue, Dec 1, 2009 at 1:11 PM, Rudi Sherry rshe...@adobe.com wrote: For (2), are we sure the relevant diff tools can isolate the real changes to those files amid mass indentation? Most if not all can, but I don't know about the automatic diffs that may be part of the webkit build/release/publish process. Not that this is a deal-breaker, but I wanted to bring it up. On Dec 1, 2009, at 12:52 PM, David Hyatt wrote: (2). On Dec 1, 2009, at 2:42 PM, Adam Barth wrote: A common false positive in the style-queue is as follows: Code inside a namespace should not be indented. [whitespace/indent] [4] That's because the namespace indent rule is fairly new and its hard to fix without touching the whole file. I don't think the style-queue should be spamming bugs with non-actionable information. There seem to be a few choices: 1) Disable this warning because it's not helpful at the moment. 2) Change our code to comply with this style rule (e.g., as we touch files, fix them so that the warning doesn't occur). 3) Change our style guide to match our code. Personally, I'm in favor of (2) because it seems silly to have a rule in our style guide with which we never plan to actually comply. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] trac.webkit.org links via Google.com
On 2009-12-01, at 12:31, Yaar Schnitman wrote:
The urls in sitemap.xml are not patterns - there are exact urls the search
engine will retrieve.
They are exact URLs that the crawler will retrieve, but they in no way restrict
the set of URLs that the crawler can retrieve.
So, you would blacklist most urls with blanket rules in robots.txt and
whitelist explicit urls in sitemap.xml. e.g. in robots.txt, blacklist
/changeset/*, and in sitemap.xml whitelist all
http://trac.webkit.org/changeset/1 to http://trac.webkit.org/changeset/6
(It's going to be a big file alright).
This proposal relies on the sitemap being treated as a whitelist that is
consulted prior to processing the exclusions listed in robots.txt. As I have
mentioned several times, I cannot find any information that states that a
sitemap acts as a whitelist, nor what its precedence relative to robots.txt
would be if it were to be treated as a whitelist. Is there something I'm
missing?
- Mark
On Tue, Dec 1, 2009 at 11:33 AM, Mark Rowe mr...@apple.com wrote:
On 2009-12-01, at 11:04, Yaar Schnitman wrote:
Robots.txt can exclude most of the trac site, and then include the
sitemap.xml. This way you block most of the junk and only give permission to
the important file. All major search engine support sitemap.xml, and those
that don't will be blocked by robots.txt.
A script could generate sitemap.xml from a local svn checkout of trunk. It
will produce one url for each source file (frequency=daily) and one url for
every revision (frequency=year). That will cover most of the search
requirements.
Forgive me, but this doesn't seem to address the issues that I raised in my
previous message.
To reiterate: We need to allow only an explicit set of URLs to be crawled.
Sitemaps do not provide this ability. They expose information about set of
URLs to a crawler, they do not limit the set of URLs that it can crawl. A
robots.txt file does provide the ability to limit the set of URLs that can be
crawled.
However, the semantics of robots.txt seem to make it incredibly unwieldy to
expose only the content of interest, if it is possible at all. For instance,
to expose http://trac.webkit.org/changeset/#{revision} while preventing
http://trac.webkit.org/changeset/#{revision}/#{path} or
http://trac.webkit.org/changeset/#{revision}?format=zipnew=#{revision}
from being crawled. Another example would be exposing
http://trac.webkit.org/browser/#{path} while preventing
http://trac.webkit.org/browser/#{path}?rev=#{revision} from being crawled.
Is there something that I'm missing?
- Mark
smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding read-only javascript properties via JavaScriptCore
Hi Geoff, So I take it that I'm understanding the API correctly? I'm currently using the WebKit framework bundled with the latest version of Safari. Should I go ahead and file a bug report? --Ryan On Dec 1, 2009, at 12:28 PM, Geoffrey Garen wrote: Sounds like a bug. Geoff On Dec 1, 2009, at 11:10 AM, Ryan Grimm wrote: Hi, I'm using the JavaScriptCore (Mac) API to add some properties into the javascript environment and would like to make sure that these properties are read only from the javascript side. From the looks of the API, I thought adding the properties with calls like this would do the trick: JSObjectSetProperty(ctx, globalObject, propertyName, propertyValue, kJSPropertyAttributeDontDelete | kJSPropertyAttributeReadOnly, NULL); The property gets added without any troubles but in javascript (and the Web Inspector) I can modify and delete the properties that I've added. Am I I missing something or just reading the docs wrong? Thanks. --Ryan ___ 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] Adding read-only javascript properties via JavaScriptCore
On Dec 1, 2009, at 2:01 PM, Ryan Grimm wrote: Hi Geoff, So I take it that I'm understanding the API correctly? I'm currently using the WebKit framework bundled with the latest version of Safari. Should I go ahead and file a bug report? Please do. Your understanding is correct, what you wrote should create a read-only property. You may also want to check if it happens if you link against the latest WebKit nightly, to verify the bug is still present. - Maciej --Ryan On Dec 1, 2009, at 12:28 PM, Geoffrey Garen wrote: Sounds like a bug. Geoff On Dec 1, 2009, at 11:10 AM, Ryan Grimm wrote: Hi, I'm using the JavaScriptCore (Mac) API to add some properties into the javascript environment and would like to make sure that these properties are read only from the javascript side. From the looks of the API, I thought adding the properties with calls like this would do the trick: JSObjectSetProperty(ctx, globalObject, propertyName, propertyValue, kJSPropertyAttributeDontDelete | kJSPropertyAttributeReadOnly, NULL); The property gets added without any troubles but in javascript (and the Web Inspector) I can modify and delete the properties that I've added. Am I I missing something or just reading the docs wrong? Thanks. --Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] namespace indent
4) (I think it may be possible to) notice that there are other unchanged lines that have this problem, and then just not print the error if that occurs. dave On Tue, Dec 1, 2009 at 12:42 PM, Adam Barth aba...@webkit.org wrote: A common false positive in the style-queue is as follows: Code inside a namespace should not be indented. [whitespace/indent] [4] That's because the namespace indent rule is fairly new and its hard to fix without touching the whole file. I don't think the style-queue should be spamming bugs with non-actionable information. There seem to be a few choices: 1) Disable this warning because it's not helpful at the moment. 2) Change our code to comply with this style rule (e.g., as we touch files, fix them so that the warning doesn't occur). 3) Change our style guide to match our code. Personally, I'm in favor of (2) because it seems silly to have a rule in our style guide with which we never plan to actually comply. Thoughts? Adam ___ 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] SharableScriptContext [was: GlobalScript in WebKit]
On Mon, Nov 30, 2009 at 10:24 PM, Oliver Hunt oli...@apple.com wrote:
All that said, Darin, Maciej and I were discussing this on IRC earlier and
it would seem that simply adding getWindowByName (or some such) would gain a
very large amount of the behaviour desired in the {Shared,
Global}Script[Context] concept.
Got to the colloquy transcript of this. I think the proposal there is to
implement getWindowByName() and not to have SharedScriptContext object at
all, rather emulate it by passing around a JS object which would be used to
share things. The argument was made that this will reduce the API explosion
and be less work in WebKit.
However, I'd need to understand how the following would work:
- it's not clear how to load script (the code that is supposed to be
shared). The apps today don't just load the whole code in a single script,
they split the script code in pieces and use script tag injection or async
XHR + eval. All of that is defined with reliance on underlying global scope
object which can not be relied upon in the proposed case. Unless JS has some
way to introduce a global scope other then default window... It seems that
'eval' method of progressive script loading breaks.
- running a JS method on a shared JS object depends on global scope used in
context of the call. In case of cross-context calls it can be very confusing
for the developers to understand which context is being used, and I think we
have some bugs in this area too (at least there are a few FIXME sprinkled
around). Having a global scope object associated with the shared script
context makes things easier to use and potentially less buggy. Not sure how
much this is the issue though.
- there were already noted issues with timers, XHR, WebSockets, (as well as
Database, Notifications etc) that simply get killed internally when their
native window closes - there is no exceptions thrown or callbacks called.
The JS wrappers that are still alive but zombied remain, but to be able to
write JS code that correctly recovers don't we need to define some behavior
of those things in case their 'native context' dies? I guess the solution is
to host those in SharedWorker, which was already noted as being not always
desirable.
I agree with desire to reduce the new APIs and this is essentially reducing
it to 0. In particular cases we currently have (GMail and Chat windows)
windows are opened via window.open() so technically we don't even need
getWindowByName() to try this approach. But, will it work? Not sure, for the
reasons above.
Dmitry
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] namespace indent
Adam's right though: unlike most of the other style changes, if we don't fix this one all at once, only new files will ever match the style guide. This is different than most of the other guidelines where things eventually converge as people touch lines of the file. On Tue, Dec 1, 2009 at 3:22 PM, David Levin le...@chromium.org wrote: 4) (I think it may be possible to) notice that there are other unchanged lines that have this problem, and then just not print the error if that occurs. dave On Tue, Dec 1, 2009 at 12:42 PM, Adam Barth aba...@webkit.org wrote: A common false positive in the style-queue is as follows: Code inside a namespace should not be indented. [whitespace/indent] [4] That's because the namespace indent rule is fairly new and its hard to fix without touching the whole file. I don't think the style-queue should be spamming bugs with non-actionable information. There seem to be a few choices: 1) Disable this warning because it's not helpful at the moment. 2) Change our code to comply with this style rule (e.g., as we touch files, fix them so that the warning doesn't occur). 3) Change our style guide to match our code. Personally, I'm in favor of (2) because it seems silly to have a rule in our style guide with which we never plan to actually comply. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] SVG Filters
Good morning WebKit crowd, I'd like to enable SVG FIlters support by default. This is the last remaining piece before we can officially claim SVG 1.0/1.1 support, in our SVG DOM implementation (through SVG requiredFeatures/ requiredExtensions functionality). Dirk has done an amazing job, providing most of our new cross-platform filter support. In previous discussions, security concerns have been raised, as the code is doing pixel-manipulations, with web content as input, so it's a place that needs special attention. Oliver specifically asked for a person not involved in reviewing the patches, but a 3rd party to check the code for potential problems. What do you think about this approach? Would anyone volunteer, for having a look over the existing filters code in trunk? Does anyone see other problems with turning on filters? Thanks for your input, Niko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] namespace indent
On Tue, Dec 1, Jeremy Orlow wrote: Adam's right though: unlike most of the other style changes, if we don't fix this one all at once, only new files will ever match the style guide. This is different than most of the other guidelines where things eventually converge as people touch lines of the file. I am in favor of using a script to do this change. It looks like we're using a similar approach to do a global rename: http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/do-webcore-rename Once created, the script could be executed on a per folder, or per project basis, etc. depending on what people prefer. I expressed interest a couple weeks ago in writing such a script: https://lists.webkit.org/pipermail/webkit-dev/2009-November/010521.html Since I don't have a time frame though, I'm not suggesting that people hold off on fixing the issue in files they touch. --Chris On Tue, Dec 1, 2009 at 3:22 PM, David Levin levin at chromium.org wrote: 4) (I think it may be possible to) notice that there are other unchanged lines that have this problem, and then just not print the error if that occurs. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Style guidelines, not hard rules
I'd like formal clarification about how we enforce our style guide.
On https://bugs.webkit.org/show_bug.cgi?id=31806#c5 , Yong Li was notified
that one of his patches violates a WebKit style rule (no {} on one-line
conditional bodies). He objected to the rule, and George Staikos commented
that the style guide rules were guidelines and not hard rules.
I'm not interested in having debates on individual bugs when people don't
like particular style guide rules. I don't happen to like this rule either,
but my impression is that we simply do not accept willful style guide
violations. Can someone with more standing in the project than me confirm
or deny that?
PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Style guidelines, not hard rules
On 2009-12-01, at 21:43, Peter Kasting wrote:
I'd like formal clarification about how we enforce our style guide.
On https://bugs.webkit.org/show_bug.cgi?id=31806#c5 , Yong Li was notified
that one of his patches violates a WebKit style rule (no {} on one-line
conditional bodies). He objected to the rule, and George Staikos commented
that the style guide rules were guidelines and not hard rules.
I'm not interested in having debates on individual bugs when people don't
like particular style guide rules. I don't happen to like this rule either,
but my impression is that we simply do not accept willful style guide
violations. Can someone with more standing in the project than me confirm or
deny that?
If individual contributors could pick and choose which rules they applied based
on their personal preference there would be little point in having the
project-wide guidelines. They exist so that personal preference doesn't need
to be considered from patch to patch, only when adopting new style guidelines
for areas not previously covered.
- Mark
smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Style guidelines, not hard rules
On 2009-12-01, at 21:48, Mark Rowe wrote:
On 2009-12-01, at 21:43, Peter Kasting wrote:
I'd like formal clarification about how we enforce our style guide.
On https://bugs.webkit.org/show_bug.cgi?id=31806#c5 , Yong Li was notified
that one of his patches violates a WebKit style rule (no {} on one-line
conditional bodies). He objected to the rule, and George Staikos commented
that the style guide rules were guidelines and not hard rules.
I'm not interested in having debates on individual bugs when people don't
like particular style guide rules. I don't happen to like this rule either,
but my impression is that we simply do not accept willful style guide
violations. Can someone with more standing in the project than me confirm
or deny that?
If individual contributors could pick and choose which rules they applied
based on their personal preference there would be little point in having the
project-wide guidelines. They exist so that personal preference doesn't need
to be considered from patch to patch, only when adopting new style guidelines
for areas not previously covered.
And to quote from http://webkit.org/coding/contributing.html:
In order for your patch to be landed, it's necessary that it comply to the
code style guidelines.
There isn't much room for interpretation in that :-)
- Mark
smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Style guidelines, not hard rules
On Dec 1, 2009, at 9:43 PM, Peter Kasting wrote:
I'd like formal clarification about how we enforce our style guide.
On https://bugs.webkit.org/show_bug.cgi?id=31806#c5 , Yong Li was
notified that one of his patches violates a WebKit style rule (no {}
on one-line conditional bodies). He objected to the rule, and
George Staikos commented that the style guide rules were guidelines
and not hard rules.
I'm not interested in having debates on individual bugs when people
don't like particular style guide rules. I don't happen to like
this rule either, but my impression is that we simply do not accept
willful style guide violations. Can someone with more standing in
the project than me confirm or deny that?
Some rules in the style guide may call for judgment and occasionally
admit exceptions, like the naming rule. But this one seems pretty
clear-cut.
Note: if people don't like this rule we can discuss changing the style
guide. But in generally people should not be picking and choosing
which style rules to follow individually. The point is to make the
code base look consistent.
Regards,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
