[webkit-dev] Need help making window.localStorage span processes
Hi everyone! I recently joined the Chrome team at Google and have been tasked with making window.localStorage work within Chromium. I've spent a good deal of time trying to understand how Chromium and WebKit interact, how the current WebKit localStorage implementation works, and thinking about how to make it all work together. Unfortunately, I'm having a really hard time coming up with an elegant solution to the problem. In WebKit, localStorage works by maintaining a string to string map for each origin and periodically syncing it to a SQLite database. This is great when render windows are all in the same memory space, but there's no simple and efficient way to make this work in a multi-process environment. (Note that even 2 windows from the same origin are usually in 2 processes within Chromium.) If you have any ideas or advice, I'd really appreciate it! Below is a dump of my ideas so far. Jeremy = (1) The easiest solution is re-sync the in-memory version of the data with what's on disk. We'd pull in the data on the first access, push the data to disk when finished, and wrap the whole thing in a transaction to block other processes form accessing localStorage until we're done. This is obviously going to be very slow and defeat the entire purpose of having an in-memory version. Doing events right and avoiding deadlocks may also be difficult as well. (2) A similar idea is to ditch the in-memory version and just work 100% from the database. In other words, every localStorage operation would result in one or more SQLite calls. We'd still need to wrap the entire thing in transactions, and I think there might still be some potential issues with events and deadlocks. It's certainly cleaner and more efficient from Chromium's perspective, but it'll be much slower than the current implementation in the single process case. (I assume this unacceptable?) (3) Another idea I had was to add a replayable log to the localStorage database. This would allow each process to efficiently catch up with the SQLite localStorage state. One complication is garbage collecting the log: we can't delete log entries until every applicable process has consumed them, but we also can't leave them lying around forever. We can't just wait until the window closes because of long running web apps (think gmail) and we have to handle corner cases like a process crashing. All three options seem viable until we add events into the equation. After that, a replay system seems necessary, and thus we're left with only the third option I mentioned. (We can't just compare what's in the database with what's in memory to generate events since a value might have changed multiple times and there's no sense of order to the events occurring.) It's also worth mentioning that, in order to make the implementation self-contained (i.e. not have hooks that Chromium or other multi-process environments must implement), WebKit would need to monitor the database file for changes. This can be tricky to do in a cross platform, scalable (i.e. not poling based) manor. It's also worth doing a back-of-the-napkin calculation for performance: I don't know the actual number of seeks for a SQLite write, but let's go with a very conservative/optimistic guess and say 3. A normal user has a 7200rpm hard drive which has an average seek of 7ms. Let's say we have n processes all accessing the same origin. So the number of times a process can modify localStorage per second before completely saturating the hard disk with seeks is something like 1000/(3*7*n) or about 50/n. So, if we have 2 windows open, the app could make the browser IO bound with just 25 updates per second per window. And that's with a very conservative estimated number of seeks, assuming nothing else is touching the disk, and assuming only one process per window. For example, if iframes were in their own process, n would be much greater for some applications. Also, if we're not careful about how garbage collection is implemented for replay log entries, even windows doing read-only access or implementing window.onstorage event handlers could slow things down. Unless I'm missing something here, it seems to me that doing interprocess communicatoin via SQLite database (or any file backing) just isn't practical. So what other options are there? (4) We do the IPC and sharing of data within a shared memory segment, and just have one process take care of the disk serialization. In order to do this, the mappings and the locks would need to be malloc'ed into this memory space. We'd also need to have some way for the memory space to be resized (for example, if the user increases its quota), which means we'd need 2 shared memory spaces per origin: a fixed size chunk for control (at very least containing a global lock and info about the other chunk) and a variable size chunk for the map. There are of course security implications when using shared memory (we're
Re: [webkit-dev] Adding new Javascript event.
I'm not sure how, but if it were me, I'd find an event that was similar to what I wanted to do and trace it through the code base to figure out how it works. On Thu, Apr 30, 2009 at 12:24 AM, Anand Patil anand...@gmail.com wrote: Hi, Similar to onload, onclick etc I would like to add new event. Could you please let me know the procedure to add new Javascript event to window object? Thanks, Anand ___ 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] Where should design descussions take place? (WAS: Bug 25436: Refactor appCache for use in multi-process browsers)
For context, the discussion started here: https://bugs.webkit.org/show_bug.cgi?id=25436 Alexey Proskuryakov said: Maybe it would make sense to discuss this on the mailing list in order to determine whether this should be a model for other projects potentially using WebKit in multi-process configuration. *I* said: As for your comment about using the mailing list, this is somewhat ironic since we've been told that it's much more helpful to have these kinds of discussions in bugs rather than the mailing list. :-) Alexey Proskuryakov said: I imagine this was probably said about a discussion of some particular bug, not of a general design issue. We were actually talking about design discussions like this one. The original context was my email on how to make localStorage multi-process aware. Where we discuss designs doesn't matter to me, but I would like to reach a consensus on the subject. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Where should design descussions take place? (WAS: Bug 25436: Refactor appCache for use in multi-process browsers)
That makes perfect sense. Sorry about the confusion. :-) J On Sat, May 2, 2009 at 3:55 PM, Maciej Stachowiak m...@apple.com wrote: On May 1, 2009, at 1:15 PM, Jeremy Orlow wrote: For context, the discussion started here: https://bugs.webkit.org/show_bug.cgi?id=25436 Alexey Proskuryakov said: Maybe it would make sense to discuss this on the mailing list in order to determine whether this should be a model for other projects potentially using WebKit in multi-process configuration. *I* said: As for your comment about using the mailing list, this is somewhat ironic since we've been told that it's much more helpful to have these kinds of discussions in bugs rather than the mailing list. :-) Alexey Proskuryakov said: I imagine this was probably said about a discussion of some particular bug, not of a general design issue. We were actually talking about design discussions like this one. The original context was my email on how to make localStorage multi-process aware. Where we discuss designs doesn't matter to me, but I would like to reach a consensus on the subject. Design discussions about new features with broad impact should be on the mailing list. These are things that the community should be aware of and that many may wish to comment on. Discussions about the details of fixing specific bugs should be in the bug. I realize there may be a fine line at times. Personally I prefer to have technical discussion on the webkit-dev list, unless it is of extremely narrow interest. I would prefer to see this list used for discussion of design issues in WebKit, instead of requests for help building or using the API or adding non-public features. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setting a size limit for Application Cache
The way I see it, there's 2 uses for AppCache in the mobile space: Simply speeding things up (i.e. just a cache) and web applications you'd like to use offline. For the first use case, automatic eviction (presumably via LRU) is quite acceptable. For the second use case, I think you need some way to pin the app in the cache. Anything that's pinned would not be subject to LRU. If the user wanted to pin an app, but the memory was full of other pinned apps, you could then present the user with an uninstall dialog. I agree that the less UI the better, but I know I'd be mad if I gmail offline stopped working simply because I hadn't visited the site in a while. J On Wed, May 6, 2009 at 11:37 AM, Jeremy Orlow jor...@google.com wrote: The way I see it, there's 2 uses for AppCache in the mobile space: Simply speeding things up (i.e. just a cache) and web applications you'd like to use offline. For the first use case, automatic eviction (presumably via LRU) is quite acceptable. For the second use case, I think you need some way to pin the app in the cache. Anything that's pinned would not be subject to LRU. If the user wanted to pin an app, but the memory was full of other pinned apps, you could then present the user with an uninstall dialog. I agree that the less UI the better, but I know I'd be mad if I gmail offline stopped working simply because I hadn't visited the site in a while. J On Wed, May 6, 2009 at 9:23 AM, Andrei Popescu andr...@google.com wrote: Hi, I was recently looking at https://bugs.webkit.org/show_bug.cgi?id=22700 I have a small patch that attempts to fix this issue by 1. allowing the ChromeClient implementers to decide what the size limit should be, 2. evicting caches (in LRU order) from the database when the size limit is reached and a new cache needs to be saved. After an initial discussion with Alexey Proskuryakov on IRC, we agreed to ask webkit-dev for advice on this matter: is LRU eviction the correct thing to do? It seems clear that the intended usage of Application Cache is to act as a repository for Web applications that can be used offline. However, when the disk space allowed for this is completely used up, would it be ok to make room for new apps by automatically evicting existing ones? The advantage of this is that it allows this feature to function without any UI at all. The drawback is that some apps would suddenly stop working offline. The alternative is to simply throw an error when the size limit is reached and expect the UA to provide some UI that allows users to free space by uninstalling existing apps. However, having another setting for this may turn out to be inconvenient (it's hard to discover and increases the burden on users who already have to deal with cookies, normal HTTP cache, databases, geolocation, etc). Many thanks, Andrei ___ 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] setting a size limit for Application Cache
Good point. Tying the apps together is pretty important. What good is it for the program to still be in AppCache if it's data (in databases or localStorage) was deleted by some other LRU policy? I'm not sure that yet another manifest is needed though. For databases and localStorage, access is controlled via the origin. It seems to me that the minimum granularity for what gets pinned is thus the domain. Yes, there can be multiple web applications per domain, but there's really no way for WebKit to know which localStorage entries or which databases are tied to each application. Thus, eviction is an all or nothing thing for the origin. This is not such a horrible thing though; authors can always create sub-domains for each web application. So, in summary: I'm proposing that there be a UI to pin (or install, or save, or whatever you want to call it) an origin + have a dialog for seeing all the origins that are pined (for uninstall purposes). All non-pinned AppCache data would be removed in a LRU fashion. J On Wed, May 6, 2009 at 12:09 PM, Michael Nordman micha...@google.comwrote: The chrome team had an interesting thread on this topic not long ago. Unfortunately it wasn't on the public chromium-dev mailing list, so I can't provide a link to it here :( summary (according to me at least:) The gist of it was that providing appcaching for general use w/o any special privileges is a good thing, but not all usages of this feature are qualitatively the same thing. In some cases it's purely about performance enhancement or reduced network utilization (traditional caching goals). In other cases it's about providing additional guarantees around application availability. Its fair to evict data cached for the former cases as needed, but not ok to evict data cached for the latter cases. There is no means for the system to distinguish between these two cases. There is no API to indicate which use is which. In the latter case (gauranteed app availability), there is more involved than the appcache... there are also databases, localstorage values to which the gaurantee extends to. What's missing is a way for applications to declare themselves as such and to establish privileges to keep data around forever. Given that, the system could relate persistent resource with applications, and based on their privileges, evict or not when space becomes an issue. A handwavvy syntax for declaring an application... html application='someurl'... the url uniquely identifies the app, the resource loaded from that url contains a user friendly description and set of desired privileges... all pages that refer to that application url are considered part of that app... all resource created on behalf of that app are tracked by the system as such. Food for thought. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setting a size limit for Application Cache
On Wed, May 6, 2009 at 1:12 PM, Michael Nordman micha...@google.com wrote: On Wed, May 6, 2009 at 12:45 PM, Jeremy Orlow jor...@google.com wrote: Good point. Tying the apps together is pretty important. What good is it for the program to still be in AppCache if it's data (in databases or localStorage) was deleted by some other LRU policy? I'm not sure that yet another manifest is needed though. For databases and localStorage, access is controlled via the origin. It seems to me that the minimum granularity for what gets pinned is thus the domain. Assuming app == domain has proven problematic. Not only are there multiple apps per domain, there are apps that span multiple domains. Yes, there can be multiple web applications per domain, but there's really no way for WebKit to know which localStorage entries or which databases are tied to each application. Thus, eviction is an all or nothing thing for the origin. This is not such a horrible thing though; authors can always create sub-domains for each web application. sub-domains for each web application has proven to be easier said than done Don't look at me. I'm not the one who made the standard. Unfortunately the standard makes it virtually impossible for offline apps to span domains and for you to cherry pick between multiple apps on one domain. We might as well embrace this fact and thus avoid creating yet another manifest. (Assuming others agree with our assumption that we do need some way to pin applications.) So, in summary: I'm proposing that there be a UI to pin (or install, or save, or whatever you want to call it) an origin + have a dialog for seeing all the origins that are pined (for uninstall purposes). All non-pinned AppCache data would be removed in a LRU fashion. Some thing the system needs is a 'trigger' to bring up such a UI. The presence of a html application='someurl' attribute, in which the descriptor file expresses it desire for the 'persistance' privilege, could provide such a trigger. I think the presence of an AppCache manifest is enough. An application can't work offline without it. On Wed, May 6, 2009 at 12:09 PM, Michael Nordman micha...@google.com wrote: The chrome team had an interesting thread on this topic not long ago. Unfortunately it wasn't on the public chromium-dev mailing list, so I can't provide a link to it here :( summary (according to me at least:) The gist of it was that providing appcaching for general use w/o any special privileges is a good thing, but not all usages of this feature are qualitatively the same thing. In some cases it's purely about performance enhancement or reduced network utilization (traditional caching goals). In other cases it's about providing additional guarantees around application availability. Its fair to evict data cached for the former cases as needed, but not ok to evict data cached for the latter cases. There is no means for the system to distinguish between these two cases. There is no API to indicate which use is which. In the latter case (gauranteed app availability), there is more involved than the appcache... there are also databases, localstorage values to which the gaurantee extends to. What's missing is a way for applications to declare themselves as such and to establish privileges to keep data around forever. Given that, the system could relate persistent resource with applications, and based on their privileges, evict or not when space becomes an issue. A handwavvy syntax for declaring an application... html application='someurl'... the url uniquely identifies the app, the resource loaded from that url contains a user friendly description and set of desired privileges... all pages that refer to that application url are considered part of that app... all resource created on behalf of that app are tracked by the system as such. Food for thought. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setting a size limit for Application Cache
2009/5/6 Alexey Proskuryakov a...@webkit.org 06.05.2009, в 23:09, Michael Nordman написал(а): There is no means for the system to distinguish between these two cases. There is no API to indicate which use is which. The first use case (just speeding things up) sounds like something that should be handled by a normal HTTP cache, as defined in RFC 2616. Is it inadequate? If it is, maybe it should be improved instead of making an additional entirely different caching mechanism? The advantage AppCaches have vs normal caches is that they're explicitly versioned by the developer. If I have a big, complex application that has many files, I can specify it all in the AppCache manifest to make it go faster (not check each file for a newer version)--even if I'm not going to make it work offline. How many developers will want to use it this way? Hard to say, but probably not too many. So maybe there should be no implicit use of AppCache...at least at first? Or am I missing some non-offline use-cases here? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] PageGroups (and the localStorage being stored in it)
I'm continuing to work on https://bugs.webkit.org/show_bug.cgi?id=25376 and noticed that the map of origins to localStorageAreas is owned by the PageGroup class. I'm having a bit of trouble understanding what exactly page groups are used for. I looked through the code and the wiki but couldn't find any explanations. I did find http://lists.macosforge.org/pipermail/webkit-dev/2008-November/005642.html which was pretty helpful, but it still doesn't make it clear to me why the localStorage map needs to reside here (rather than being some global/singleton object). Thanks! Jeremy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] PageGroups (and the localStorage being stored in it)
On Thu, May 7, 2009 at 5:25 PM, Darin Adler da...@apple.com wrote: On May 7, 2009, at 4:56 PM, Jeremy Orlow wrote: I'm continuing to work on https://bugs.webkit.org/show_bug.cgi?id=25376 and noticed that the map of origins to localStorageAreas is owned by the PageGroup class. I'm having a bit of trouble understanding what exactly page groups are used for. PageGroup exists so you can have multiple web pages in a single application that share state, including frame namespace, such as the multiple windows and tabs in Safari. Separate page groups allow other web views to be separate, allowing the same application to use WebKit for things that should be isolated from web browsing; for example Safari on Windows uses web views for things like Preferences and text input. This is exposed as part of the WebKit API on Mac OS X, with the setGroupName: method. It may be a useless concept for Chromium but it’s critical on Mac OS X. Didn't mean to imply they were useless, at all. Was just trying to understand their use. Thanks! J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] PageGroups (and the localStorage being stored in it)
One more question: are there any use cases where setGroupName could occur after window.localStorage() had been called? If so, this seems like it could be a problem since a Storage object is only created on the first call to DOMWindow::localStorage() and then it's cached as a member variable in DOMWindow. This would mean that any page that calls window.localStorage() before setGroupName is called would not be using the same localStorageArea as a page that calls setGroupName first. Also, is there any significance to setGroupName being reset to nothing during Page's destructor? Jeremy On Thu, May 7, 2009 at 8:07 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, May 7, 2009 at 5:25 PM, Darin Adler da...@apple.com wrote: On May 7, 2009, at 4:56 PM, Jeremy Orlow wrote: I'm continuing to work on https://bugs.webkit.org/show_bug.cgi?id=25376 and noticed that the map of origins to localStorageAreas is owned by the PageGroup class. I'm having a bit of trouble understanding what exactly page groups are used for. PageGroup exists so you can have multiple web pages in a single application that share state, including frame namespace, such as the multiple windows and tabs in Safari. Separate page groups allow other web views to be separate, allowing the same application to use WebKit for things that should be isolated from web browsing; for example Safari on Windows uses web views for things like Preferences and text input. This is exposed as part of the WebKit API on Mac OS X, with the setGroupName: method. It may be a useless concept for Chromium but it’s critical on Mac OS X. Didn't mean to imply they were useless, at all. Was just trying to understand their use. Thanks! J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] SessionStorage being serialized to disk
Is anyone here dead set against window.sessionStorage ever being written out to disk (in an unencrypted form)? Session storage needs to be stored for the life of the Page class since the user can always navigate back to a site or hit the back button. This means that a very long lived tab could start wasting a lot of memory in a world where session storage is commonly used. The only reason I've heard against writing session storage to disk is security. For example, a web site storing some security token client side. Unfortunately, you never know when your memory is going to get paged to disk, so if we're serious about keeping session storage secure, we'd need to address that--at least for sites using HTTPS. The spec itself doesn't explicitly say either way. It does suggest that the lifetime of a browsing context (and thus session storage) is not necessarily connected to the lifetime of a browsing process. Since some crash recovery implementations work by serializing the browsers state to disk, the spec seems to be suggesting that it _can_ be written to disk, but I'm not aware of any browsers actually doing this yet. If we did feel strongly about making security guarantees for session storage, we should probably suggest on WhatWG that it be guaranteed by the spec. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Controling HTML5 local storage/ databases programmatically
On Tue, May 12, 2009 at 11:12 AM, Christian Dywan christ...@twotoasts.dewrote: Heya, inspired by bug 25629 [1] I came to wonder how far webkit applications are able to control HTML5 local storage and databases. The bug report is mainly about enabling or disabling these features. So how far does WebCore allow for limiting stored data, in the form of an expiration date and in the form of disk quota? And how can one listen to changes, and manipulate data? There's no quota support in local storage (yet..I'll probably be looking at this eventually). I don't believe there's any intention to have expiration dates for database, LocalStorage, or AppCache, but there has been talk of a LRU policy of eviction when devices are running out of storage space. I am thinking of ways similar to HTTP cookies, where I can easily see what is added, changed, removed and where data is coming from. Any tips as for how to do this from within WebCore, so that WebKit, specifically WebKitGTK+, can provide API for this, would be greatly appreciated. There's no standard across the APIs for doing anything like this. It shouldn't be too hard to add to localStorage since it already has an event system. Not sure about the others, but I assume it'd take more work. Apologies for throwing local storage and databases in the same pot here. I'm aware these are distinct features. Yours, Christian [1] https://bugs.webkit.org/show_bug.cgi?id=25629 ___ 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] squirrelfish-bytecode
On Wed, May 13, 2009 at 1:11 AM, Maciej Stachowiak m...@apple.com wrote: On May 13, 2009, at 12:18 AM, Meryl Silverburgh wrote: Hi, Does webkit cache squirrelfish bytecode? For example, multiple can use the same javascript file (e.g. common javascript libraries, like jquery, or same domain uses some common javascript file across different pages for the same domain). When webkit parses the JS file and builds squirrelfish-bytecode, does it cache it ? so that subsequence loading of the same js file will skip the js compile process? We don't currently cache the bytecode (or the native code). It is an option we have considered, however, currently, code generation is a trivial portion of JS execution time ( 2%), so we're not pursuing this at the moment. What does the 2% number reflect? The percent of time while running a particular benchmark or something? I totally believe that the speed of runtime is not really affected by it, but what about page load latency? Compile time is a non-trivial component of load time for most JIT compilers I've heard of. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Proposal for refactoring DOM Storage
I've been researching, prototyping, and generally thinking about
https://bugs.webkit.org/show_bug.cgi?id=25376 for a while now. I think I
now know what needs to be done and the least painful way to get there. I've
written up a design doc which is available here:
http://docs.google.com/Doc?id=dhs4g97m_8cwths74m
If you'd like write permissions to it so you can add comments inline (via
Ctrl-M), shoot me an email. If you'd rather reply inline via email, feel
free to do that as well.
J
===
WebCore DOM Storage Refactoring Design DocOverview and The Need:See
https://bugs.webkit.org/show_bug.cgi?id=25376 for the related bug.
The current design of DOM Storage (i.e. window.LocalStorage and
window.SessionStorage) within WebCore is fairly incompatible with
multi-process browsers like Chromium. This can be fixed with a clean
frontend/backend split within DOM Storage, allowing multi-process browsers
to implement a proxy layer between the two, and having all the frontends
share one backend. The design should not assume that pages within the same
origin are in the same process, that a cloned (see the SessionStorage spec)
top level browsing context will remain in the same process, or that all
children of a top level browsing context are in the same process.
Note that the current DOM Storage implementation is such that memory is
rarely ever reclaimed (currently only from SessionStorage and only when tabs
are closed). The refactored backend should be designed so it's practical to
reclaim resources when tabs close, child processes crash, users navigate
away from pages, etc. That said, actually reclaiming resources is
considered future work.
High level plan:There are 2 main classes that will be added to WebCore:
StorageBackend and StorageEventManager. StorageBackend will be a singleton
that can be replaced with a proxy class. The StorageEventManager is
instantiated in a way that can easily be overridden by a StorageBackend
proxy class. Currently, the LocalStorage and SessionStorage classes keep
track of StorageAreas and own the syncing threads/queues. This
functionality will be moved into the StorageBackend and the
StorageSyncManager (which is owned by the StorageBackend). The StorageArea
classes' event dispatching will be moved into the StorageEventManger class
since the events may originate from another process via a proxy.
Since the Local and SessionStorage code is going to be more and more similar
as time goes on, some of the classes (like LocalStorageArea and
SessionStorageArea) will probably be combined and the behavior of the class
will be determined explicitly rather than via polymorphism. For example,
the StorageArea will have a flag that says whether or not the in memory map
is backed by a database.
The actual work will be split into as many patches as possible so the work
is easy to verify as correct. The performance of Local/SessionStorage
should not be significantly affected at any point. For example, there are
no new lookup tables required except within Proxy classes.
Stage 1:Move LocalStorage and SessionStorage logic into Backend and
EventManager.
Stage 2:Create a StorageSyncManager class that abstracts all the
Synchronization work. Combine LocalStorageArea and SessionStorageArea.
Rename LocalStorageThread/Task StorageSyncThread/Task.
Stage 3:Add hooks for multi-process setups.
Traces through the new design:To help make things clear, here's what would
happen in a single-process environment for a page that simply does the
following: window.localStorage.setItem('key', 'value')
*Javascript bindings convert window.localStorage to DOMWindow.localStorage()
*
DOMWindow.localStorage()
*// StorageBackend::backend() is a singleton that returns a proxy for
multi-process setups.*
storage_area = StorageBackend::backend()-createLocalStorage(page_group,
security_origin)
storage = Storage::create(frame, stroage_area) *// normal stuff +
registers the storage area with the event manager*
*// In a multi-process environment, parts of this are on the backend and
parts are on the frontend*
StorageBackend.createLocalStorage(page_group, security_origin)
id = createUniqueIdFromPageGroupAndSecurityOrigin(page_group, security)
if storageAreaMap.contains(id):
storageArea = storageAreaMap.get(id)
else
storage_area = StorageArea::createLocalStorageArea(id, eventDispatcher,
storageSyncManager) *// constructor just initializes instance variables*
storageSyncManager.scheduleImport(storage_area) *// imports are
scheduled before writes to disk*
storageAreaMap.set(id, storage_area)
return storage_area.release()
*Javascript bindings call setItem on the returned object*
Storage.setItem(key, value, exception_code_out)
return m_storageArea.setItem(m_frame, key, value, exception_code_out)
*// In a multi-process environment, DONE ON THE BACKEND*
StorageArea.setItem(frame, key, value, exception_code_out)
*// Abstracting out the manager allows
[webkit-dev] DOM Storage and private browsing
I'm pretty confused by the policy decisions in DOM Storage with respect to private browsing. When in private browsing, both LocalStorage and SessionStorage return QUOTA_EXCEEDED_ERR whenever setItem() is called and simply ignore removeItem() and clear() calls. This is different from the behavior when LocalStorage persistence is disabled (because page-settings()-localStorageDatabasePath() returns nothing) which returns a LocalStorage object that is not database backed. According to a FIXME in LocalStorage::fullDatabaseFilename [2], there's also plans to allow LocalStorage (but just not back it with a database) when there is no quota. The first question is why private browsing affects SessionStorage? The original email [1] on the matter didn't mention changing this, and I can't see any reason why it needs to. Next, why the (planned) inconsistency in quota handling? This seems to go against the Apple view on LocalStorage persistence ([doing this] would lead to bizarre behavior where data that the application thought was saved really wasn't is the only example I could find in 1 minute, but I believe there's others in [3] and other threads). It also seems confusing that the script would get a QUOTA_EXCEEDED_ERR if there's a tiny quota but would just get a non-database backed storage if there's 0 quota. Lastly, I have to ask (at the risk of rehashing [3]) why private browsing gives access to data accumulated before entering private browsing (which could be sensitive and user identifying!) and why it's considered ok to silently ignore requests to clear/remove data (even though it's not OK according to [1] to offer a non-persistent LocalStorage). I'm sorry if these questions sound antagonistic, but I just want to understand what the overall way of thinking/vision is here. Just to be clear, I understand that Safari's private browsing has a different philosophy from Chromium's incognito mode. I'm bringing this up because (as far as I can tell) WebKit is not consistent internally. If any changes need to be made as a result of this discussion, I'm happy to make them. :-) Jeremy [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/019238.html [2] http://svn.webkit.org/repository/webkit/trunk/WebCore/storage/LocalStorage.cpp [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/thread.html#19238 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM Storage and private browsing
Thanks a lot for the quick response. This does clear up a lot for me. Hopefully I'll send my first DOM Storage re-factoring [1] patch out in a day or two. Once the re-factoring is squared away, I'll try to tackle these inconsistencies. (And, a little further out, I'm hoping to add Quota support and memory reclamation code.) In the mean time I'll file a bug. Note that, with respect to some of these corner cases, I think Chromium's behavior may need diverge from the default WebKit behavior. (For example, incognito mode will be different from WebKit's private browsing.) That said, I think it should be pretty easy to handle these differences in a clean manner. Thanks, Jeremy [1] https://lists.webkit.org/pipermail/webkit-dev/2009-May/007684.html On Wed, May 20, 2009 at 1:38 PM, Brady Eidson beid...@apple.com wrote: On May 20, 2009, at 1:03 PM, Jeremy Orlow wrote: I'm pretty confused by the policy decisions in DOM Storage with respect to private browsing. Just to be clear, I understand that Safari's private browsing has a different philosophy from Chromium's incognito mode. Right. To re-clarify for this discussion: WebKit's private browsing feature exists as direct result of the design of Safari's private browsing feature from many years ago. Safari's private browsing feature has always been about do not leave any local footprint on the user's disk pertaining to this browsing session and has never been about creating an anonymous profile for the wild. Take a look at cookies, for example - a private browsing session starts with an in-memory copy of the cookies that existed at the time the session starts. Any changes to cookies during the session are not persisted to disk. When the private browsing session is over, we revert back to the stored cookies as they existed when private browsing began. We definitely discussed applying that model to LocalStorage, and it's certainly not off the table to do so. But such a solution would be much more complex, and were more concerned with closing the LocalStorage changes are written to disk during private browsing bug in the meantime. When in private browsing, both LocalStorage and SessionStorage return QUOTA_EXCEEDED_ERR whenever setItem() is called and simply ignore removeItem() and clear() calls. This is different from the behavior when LocalStorage persistence is disabled (because page-settings()-localStorageDatabasePath() returns nothing) which returns a LocalStorage object that is not database backed. I think this is a bug. The crux of the emails to whatwg that you reference is that we have two strong convictions: 1 - LocalStorage is guaranteed to be persistent. We're giving web developers simple, reliable, persistent storage and we plan to treat it like user data that only the controlling web apps or users themselves can make decisions about 2 - Since LocalStorage is guaranteed to be persistent, we should never give a web app the indication that we've stored some data when we actually have no intention to store it. If we can get a LocalStorage object that is not database backed, this goes against that philosophy and is a potential bug. According to a FIXME in LocalStorage::fullDatabaseFilename [2], there's also plans to allow LocalStorage (but just not back it with a database) when there is no quota. The first question is why private browsing affects SessionStorage? The original email [1] on the matter didn't mention changing this, and I can't see any reason why it needs to. From the ChangeLog for r42302 - ...made the change to restrict SessionStorage to read-only, also, with the understanding that the spec allows for SessionStorage to persist across relaunches, even though our implementation currently doesn't do this. This may have been overzealous preparation for the future, but hopefully it explains the thinking behind it. Next, why the (planned) inconsistency in quota handling? This seems to go against the Apple view on LocalStorage persistence ([doing this] would lead to bizarre behavior where data that the application thought was saved really wasn't is the only example I could find in 1 minute, but I believe there's others in [3] and other threads). It also seems confusing that the script would get a QUOTA_EXCEEDED_ERR if there's a tiny quota but would just get a non-database backed storage if there's 0 quota. As said above, if we can't back a LocalStorage object with a database, we shouldn't be pretending to store data in it. This is a bug. Same with 0 quota. It should probably end up having the read-only behavior as currently implemented for private browsing. Lastly, I have to ask (at the risk of rehashing [3]) why private browsing gives access to data accumulated before entering private browsing (which could be sensitive and user identifying!) and why it's considered ok to silently ignore requests to clear/remove data (even though it's not OK
Re: [webkit-dev] DOM Storage and private browsing
Oh, and I forgot to mention: given your philosophy on private browsing and the potential for session data being written to disk in the future, I think it's reasonable to disallow writing to SessionStorage while in private browsing mode. I'll add a comment in the StorageArea.cpp code explaining this decision. J On Wed, May 20, 2009 at 2:01 PM, Jeremy Orlow jor...@chromium.org wrote: Thanks a lot for the quick response. This does clear up a lot for me. Hopefully I'll send my first DOM Storage re-factoring [1] patch out in a day or two. Once the re-factoring is squared away, I'll try to tackle these inconsistencies. (And, a little further out, I'm hoping to add Quota support and memory reclamation code.) In the mean time I'll file a bug. Note that, with respect to some of these corner cases, I think Chromium's behavior may need diverge from the default WebKit behavior. (For example, incognito mode will be different from WebKit's private browsing.) That said, I think it should be pretty easy to handle these differences in a clean manner. Thanks, Jeremy [1] https://lists.webkit.org/pipermail/webkit-dev/2009-May/007684.html On Wed, May 20, 2009 at 1:38 PM, Brady Eidson beid...@apple.com wrote: On May 20, 2009, at 1:03 PM, Jeremy Orlow wrote: I'm pretty confused by the policy decisions in DOM Storage with respect to private browsing. Just to be clear, I understand that Safari's private browsing has a different philosophy from Chromium's incognito mode. Right. To re-clarify for this discussion: WebKit's private browsing feature exists as direct result of the design of Safari's private browsing feature from many years ago. Safari's private browsing feature has always been about do not leave any local footprint on the user's disk pertaining to this browsing session and has never been about creating an anonymous profile for the wild. Take a look at cookies, for example - a private browsing session starts with an in-memory copy of the cookies that existed at the time the session starts. Any changes to cookies during the session are not persisted to disk. When the private browsing session is over, we revert back to the stored cookies as they existed when private browsing began. We definitely discussed applying that model to LocalStorage, and it's certainly not off the table to do so. But such a solution would be much more complex, and were more concerned with closing the LocalStorage changes are written to disk during private browsing bug in the meantime. When in private browsing, both LocalStorage and SessionStorage return QUOTA_EXCEEDED_ERR whenever setItem() is called and simply ignore removeItem() and clear() calls. This is different from the behavior when LocalStorage persistence is disabled (because page-settings()-localStorageDatabasePath() returns nothing) which returns a LocalStorage object that is not database backed. I think this is a bug. The crux of the emails to whatwg that you reference is that we have two strong convictions: 1 - LocalStorage is guaranteed to be persistent. We're giving web developers simple, reliable, persistent storage and we plan to treat it like user data that only the controlling web apps or users themselves can make decisions about 2 - Since LocalStorage is guaranteed to be persistent, we should never give a web app the indication that we've stored some data when we actually have no intention to store it. If we can get a LocalStorage object that is not database backed, this goes against that philosophy and is a potential bug. According to a FIXME in LocalStorage::fullDatabaseFilename [2], there's also plans to allow LocalStorage (but just not back it with a database) when there is no quota. The first question is why private browsing affects SessionStorage? The original email [1] on the matter didn't mention changing this, and I can't see any reason why it needs to. From the ChangeLog for r42302 - ...made the change to restrict SessionStorage to read-only, also, with the understanding that the spec allows for SessionStorage to persist across relaunches, even though our implementation currently doesn't do this. This may have been overzealous preparation for the future, but hopefully it explains the thinking behind it. Next, why the (planned) inconsistency in quota handling? This seems to go against the Apple view on LocalStorage persistence ([doing this] would lead to bizarre behavior where data that the application thought was saved really wasn't is the only example I could find in 1 minute, but I believe there's others in [3] and other threads). It also seems confusing that the script would get a QUOTA_EXCEEDED_ERR if there's a tiny quota but would just get a non-database backed storage if there's 0 quota. As said above, if we can't back a LocalStorage object with a database, we shouldn't be pretending to store data in it. This is a bug. Same with 0 quota
Re: [webkit-dev] SharedWorkers alternate design
On Fri, May 22, 2009 at 2:25 PM, Drew Wilson atwil...@google.com wrote: Following up on this, I had a question about the best way to enable the implementation of SharedWorkerRepository to vary for different platforms. I'd like to provide a default WebKit implementation, but on Chromium we'll want to provide an implementation that proxies shared worker operations to the browser process - it is unlikely that the two implementations will share very much (any?) code. The current design just defines SharedWorkerRepository as an interface, then has a platform-specific static factory which returns an instance of this class - the idea is that I'd provide a default WebKit implementation (called SharedWorkerProxyImpl.cpp?), then Chromium (or other platforms that want their own implementation) can provide their own factory method and implementation (for an example of this, see WorkerContextProxy::create() in WebCore/worker/WorkerMessagingProxy.cpp. Is this an acceptable approach? Other approaches I've seen either scatter ifdefs around in header files (see KURL.h for an example) which seems non-ideal for our case which won't have any shared code, or to have separate platform-specific subdirectories, but I'm not certain what the naming convention is for a directory that contains implementation for everything but chromium. I think the interface + static factory approach is the cleanest, This is the gist of what I'm planning for LocalStorage and I believe what Michael's planning for AppCache. At least in my case, I think I'll be able to share a substantial amount of code by running the backend of the code in the chromium browser process. but I've gotten the impression that the use of virtual functions to vary implementations per-platform is frowned upon in WebKit. Any advice for me? -atw On Fri, May 22, 2009 at 1:20 PM, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: I believe Qt uses instance() in this situation. Sadly we have not yet found a good verb for the common get or create idiom. Cheers. Kenneth ___ 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] Browser issue with multiple tabulators
This is _exactly_ the use case SessionStorage was developed for. :-) On Fri, May 22, 2009 at 2:41 PM, Darin Adler da...@apple.com wrote: I believe HTML 5’s sessionStorage is intended to resolve this issue. -- 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] SharedWorkers alternate design
Note that Chromium uses the same binary/libraries for the render process and the browser process, which means that the decision can't be made in compile time for us. There might be ways (like what you mentioned) to allow the compiler to skip all the virtual stuff for implementations where the decision can be made in compile time (the normal case). I've got some ideasI'll try to explain them when I get a second later this afternoon. J On Tue, May 26, 2009 at 10:43 AM, Drew Wilson atwil...@google.com wrote: Thanks for the explanation, Maciej. I actually looked at ResourceRequest prior to sending my mail, but I wasn't clear what makefile magic was being used to load the correct version of ResourceRequest.h for a given platform. For example, if I look at WebCore/WebCore.vcproj/WebCore.vcproj, I see only two references to ResourceRequest.h: platform/network/curl and platform/network/cf, but clearly we might want to use the chromium/ or win/ versions as well. Can someone give me a quick explanation of how the platform-specific version is selected at compile time? Do we have a naming convention for the default implementation? I'm expecting there to be two versions of SharedWorkerRepository - the chromium version, and the everything else version. -atw On Tue, May 26, 2009 at 10:36 AM, Maciej Stachowiak m...@apple.com wrote: On May 26, 2009, at 10:21 AM, Darin Adler wrote: On May 26, 2009, at 10:16 AM, Drew Wilson wrote: OK, I've got two strong votes for the interface + static factory approach. Any objections from the rest of the WebKit team? If I don't hear any counter proposals, I'll do that. I think it's unpleasant to pay run-time cost for a compile-time choice. Sure, sometimes the extra cost is no big deal, but sometimes it can be a big deal and I see no reason to choose idioms that use virtual functions if there are equally good or better ones that don't. Are there really no better techniques than abstract base classes and virtual functions for this sort of compile-time switch? How about the technique used for ResourceRequest and ResourceResponse? Maybe Darin Fisher can explain that one. I agree with Darin's comments here. We've tried hard to avoid using runtime polymorphism for compile-time choices. Here it's probably not performance-critical, but it can be avoided. The ResourceRequestBase / ResourceRequest model (due to Darin Fisher) seems pretty clean to me. I would like to see more of our classes with port-specific implementation details move to this style. I think it could work for SharedWorkerRepository. The basic idea is this. Let's say you have a class FooBar. - You define a FooBarBase class that has the cross-platform interface and data members. But not all the methods are actually implemented in the cross-platform code. All of its constructors are protected so the class cannot be instantiated directly. - Each port subclasses FooBarBase to define FooBar, adding constructors, platform-specific data members, and any needed platform-specific private helpers or type conversions. - Each port implements the methods of FooBarBase that are platform-specific, freely downcasting to FooBar when needed since we have guaranteed that every instance of FooBarBase is actually a FooBar. - Cross-platform code using the class just uses FooBar. The Base class is an implementation detail. (Darin F., please correct me if I have not done justice to this technique.) Note that this method has no runtime cost - there's no need to use virtual methods or other forms of runtime indirection. And there's no need to #ifdef any headers, everything is controlled purely by including the right platform specific FooBar.h so it can be handled by include paths. It's a little subtle at first but I think it results in nice, understandable code. I think we should document this technique as the preferred way to make classes with port-specific implementation details and convert more of WebCore/platform/ to this technique, as well as using it for new classes. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
The common case is definitely that we know whether we want the proxy (for IPC) or the implementation at compile time. In some cases (like Chromium) this is not known until initialization time. So the ideal is a clean way to handle the not known until initialization while optimizing for the compile time case. Here's a proposal: For the compile time decision case, do everything the same as it's done in ResourceRequest: Have an interface (StorageBackendInterface), a Base class (except in this case we'll have 2 which we'll call StorageBackendImpl and StorageBackendProxy), and then the class everything uses (StorageBackend). The decision of which base class StorageBackend should inherit from can be made based on a preprocessor define. Everything basically works as Maciej suggested. For the initialization time decision case, we flip things on their head: we prepend virtual to every method declaration in StorageBackend (via a define that's either virtual or ) and switch the inheritance order so that StorageBackendImpl/Proxy inherit from StorageBackend. Now all those casts we were doing above (i.e. StorageBackendImpl casting itself to StorageBackend and calling a method) are completely legal type system wise (because they're casting it to a base class). Additionally, any calls to functions that used to be inherited (i.e. StorageBackend making a call to something in StorageBackendImpl) are ok because it's just doing a virtual dispatch. (The key is that every function shared between the StorageBackend and the Impl/Proxy needs to be declared in the Interface.) This still seems really ugly and overly complicated. I'm actually about to send out code for https://bugs.webkit.org/show_bug.cgi?id=25376 that uses plain old virtual dispatch and everything runs at exactly the same speed it used to. (I made an ad-hoc benchmark so I could double check such things.) SoI'm really not sure all of this trickery makes sense for what I'm working on, but it might be necessary elsewhere. J On Tue, May 26, 2009 at 11:11 AM, Jeremy Orlow jor...@chromium.org wrote: Note that Chromium uses the same binary/libraries for the render process and the browser process, which means that the decision can't be made in compile time for us. There might be ways (like what you mentioned) to allow the compiler to skip all the virtual stuff for implementations where the decision can be made in compile time (the normal case). I've got some ideasI'll try to explain them when I get a second later this afternoon. J On Tue, May 26, 2009 at 10:43 AM, Drew Wilson atwil...@google.com wrote: Thanks for the explanation, Maciej. I actually looked at ResourceRequest prior to sending my mail, but I wasn't clear what makefile magic was being used to load the correct version of ResourceRequest.h for a given platform. For example, if I look at WebCore/WebCore.vcproj/WebCore.vcproj, I see only two references to ResourceRequest.h: platform/network/curl and platform/network/cf, but clearly we might want to use the chromium/ or win/ versions as well. Can someone give me a quick explanation of how the platform-specific version is selected at compile time? Do we have a naming convention for the default implementation? I'm expecting there to be two versions of SharedWorkerRepository - the chromium version, and the everything else version. -atw On Tue, May 26, 2009 at 10:36 AM, Maciej Stachowiak m...@apple.comwrote: On May 26, 2009, at 10:21 AM, Darin Adler wrote: On May 26, 2009, at 10:16 AM, Drew Wilson wrote: OK, I've got two strong votes for the interface + static factory approach. Any objections from the rest of the WebKit team? If I don't hear any counter proposals, I'll do that. I think it's unpleasant to pay run-time cost for a compile-time choice. Sure, sometimes the extra cost is no big deal, but sometimes it can be a big deal and I see no reason to choose idioms that use virtual functions if there are equally good or better ones that don't. Are there really no better techniques than abstract base classes and virtual functions for this sort of compile-time switch? How about the technique used for ResourceRequest and ResourceResponse? Maybe Darin Fisher can explain that one. I agree with Darin's comments here. We've tried hard to avoid using runtime polymorphism for compile-time choices. Here it's probably not performance-critical, but it can be avoided. The ResourceRequestBase / ResourceRequest model (due to Darin Fisher) seems pretty clean to me. I would like to see more of our classes with port-specific implementation details move to this style. I think it could work for SharedWorkerRepository. The basic idea is this. Let's say you have a class FooBar. - You define a FooBarBase class that has the cross-platform interface and data members. But not all the methods are actually implemented in the cross-platform code. All of its constructors are protected so the class
Re: [webkit-dev] SharedWorkers alternate design
On Tue, May 26, 2009 at 5:05 PM, Sam Weinig sam.wei...@gmail.com wrote: On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow jor...@chromium.org wrote: The common case is definitely that we know whether we want the proxy (for IPC) or the implementation at compile time. In some cases (like Chromium) this is not known until initialization time. What do you mean by initialization time? Is it the case that you know which one you want at each call site? Or do literally want to make a runtime choice based on state? Well, I meant that we always want one or the other based on if the process is being used as a render process (i.e. sandboxed, running WebKit but with all DOM Storage calls proxied) or a browser process (i.e. running only selected parts of WebCore like the DOM Storage backend/implementation). Come to think of it (IIRC) all calls to the StorageBackend within the WebCore code should go through a proxy for Chromium. The proxy will then call into Chromium's webkit bridge/glue, which will pass the message through the IPC layer, which will call back into bridge/glue code, which will be interacting with the real implementation. If that's true, then the implementation could be very explicitly split into 2 (with frontend code calling backend proxy code and vice versa) and single process implementations could simply typedef _Proxy to _Impl (or Implementation, or Base, or whatever you want to call it). or have I completely confused myself? J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On Tue, May 26, 2009 at 5:21 PM, Jeremy Orlow jor...@chromium.org wrote: On Tue, May 26, 2009 at 5:05 PM, Sam Weinig sam.wei...@gmail.com wrote: On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow jor...@chromium.orgwrote: The common case is definitely that we know whether we want the proxy (for IPC) or the implementation at compile time. In some cases (like Chromium) this is not known until initialization time. What do you mean by initialization time? Is it the case that you know which one you want at each call site? Or do literally want to make a runtime choice based on state? Well, I meant that we always want one or the other based on if the process is being used as a render process (i.e. sandboxed, running WebKit but with all DOM Storage calls proxied) or a browser process (i.e. running only selected parts of WebCore like the DOM Storage backend/implementation). Come to think of it (IIRC) all calls to the StorageBackend within the WebCore code should go through a proxy for Chromium. The proxy will then call into Chromium's webkit bridge/glue, which will pass the message through the IPC layer, which will call back into bridge/glue code, which will be interacting with the real implementation. If that's true, then the implementation could be very explicitly split into 2 (with frontend code calling backend proxy code and vice versa) and single process implementations could simply typedef _Proxy to _Impl (or Implementation, or Base, or whatever you want to call it). or have I completely confused myself? To clarify, I'm saying that your question made me realize that we probably can make a hard split between the frontend and backend code (i.e. what would live in a sandbox and handle page rendering and what wouldn't live in a sand box and store the actual DOM Storage data). In single process cases where there is no IPC barrier, and thus no proxy (and thus the actual implementation code should be called directly) a typedef should bridge the 2 with no run time performance penalty. Darin, Sam, Maciej: does this alleviate your concerns? Michael, Drew, John: do you think it'd work for workers/appcache as well? Everyone: have I completely missed something here? J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On Tue, May 26, 2009 at 6:02 PM, Michael Nordman micha...@google.comwrote: To clarify, I'm saying that your question made me realize that we probably can make a hard split between the frontend and backend code (i.e. what would live in a sandbox and handle page rendering and what wouldn't live in a sand box and store the actual DOM Storage data). In single process cases where there is no IPC barrier, and thus no proxy (and thus the actual implementation code should be called directly) a typedef should bridge the 2 with no run time performance penalty. Darin, Sam, Maciej: does this alleviate your concerns? Michael, Drew, John: do you think it'd work for workers/appcache as well? Partly. The split you just described is what I have in mind for the scripting related appcache interfaces. There always exists a hard split between front and back. The nature of the proxy is different depending. Btw, I also have in mind to use webcore's backend appache code in the seperate process (chrome's main process). The appcache is complicated by the fact that in addition to the scripting related interfaces, there are also interfaces around loading resources out of the cache. The loader currently calls into the appcache and wants an answer immediately (syncrhronously). These call happen at times not so friendly to remoting, like in advance of checking the memory cache... so I don't like the idea of injecting sync IPC calls at those times. I'm still wrestling with that part. I have in mind to overload ResourceHandle such that it knows how to load out of the appropiate appcache when needed, but what I haven't worked thru are how this plays well with webcore's memory cache. Did you say partly because it's more complicated than just splitting one class (and only having 1-way sync communication)? If so, then we're still on the same page, because that's what I'll be doing as well. I was just using the StorageBackend as an example, but events will require signals from the backend to the frontend, and some abstractions (like StorageArea) make a lot of sense whether or not things are split into two pieces, which sounds a lot like what you described with ResourceHandle. If not, what cases are there where you can't cleanly split things into the 2 buckets: call the proxy if it exists, otherwise call the implementation and ALWAYS call the implementation ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
It might also be worth bringing back up the unanswered quesiton of whether this is even worth it for AppCache and LocalStorage. As I mentioned, my (less than scientific) testing indicated no.* Maybe we're prematurely optimizing here? I definitely agree that virtual functions should be avoided in code that's often called, but even AppCache doesn't really seem to fit into that category. Jeremy * I have a test page that calls window.localStorage 100,000 times, localStorage.setItem(foo, bar) 100,000 times, and localStorage.getItem(foo) 1,000,000 times. All of these take under half a second, and the times don't really change with my new implementation which does use virtual dispatch. On Tue, May 26, 2009 at 7:00 PM, John Abd-El-Malek j...@google.com wrote: On Tue, May 26, 2009 at 5:31 PM, Jeremy Orlow jor...@chromium.org wrote: On Tue, May 26, 2009 at 5:21 PM, Jeremy Orlow jor...@chromium.orgwrote: On Tue, May 26, 2009 at 5:05 PM, Sam Weinig sam.wei...@gmail.comwrote: On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow jor...@chromium.orgwrote: The common case is definitely that we know whether we want the proxy (for IPC) or the implementation at compile time. In some cases (like Chromium) this is not known until initialization time. What do you mean by initialization time? Is it the case that you know which one you want at each call site? Or do literally want to make a runtime choice based on state? Well, I meant that we always want one or the other based on if the process is being used as a render process (i.e. sandboxed, running WebKit but with all DOM Storage calls proxied) or a browser process (i.e. running only selected parts of WebCore like the DOM Storage backend/implementation). Come to think of it (IIRC) all calls to the StorageBackend within the WebCore code should go through a proxy for Chromium. The proxy will then call into Chromium's webkit bridge/glue, which will pass the message through the IPC layer, which will call back into bridge/glue code, which will be interacting with the real implementation. If that's true, then the implementation could be very explicitly split into 2 (with frontend code calling backend proxy code and vice versa) and single process implementations could simply typedef _Proxy to _Impl (or Implementation, or Base, or whatever you want to call it). or have I completely confused myself? To clarify, I'm saying that your question made me realize that we probably can make a hard split between the frontend and backend code (i.e. what would live in a sandbox and handle page rendering and what wouldn't live in a sand box and store the actual DOM Storage data). In single process cases where there is no IPC barrier, and thus no proxy (and thus the actual implementation code should be called directly) a typedef should bridge the 2 with no run time performance penalty. Darin, Sam, Maciej: does this alleviate your concerns? Michael, Drew, John: do you think it'd work for workers/appcache as well? This will work fine for appcache and localstorage, but isn't sufficient for workers since the same caller gets different objects depending on which process this is running in. This doesn't happen for appcache and localstorage. Everyone: have I completely missed something here? J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On Tue, May 26, 2009 at 9:40 PM, Maciej Stachowiak m...@apple.com wrote: On May 26, 2009, at 6:11 PM, Jeremy Orlow wrote: Did you say partly because it's more complicated than just splitting one class (and only having 1-way sync communication)? If so, then we're still on the same page, because that's what I'll be doing as well. I was just using the StorageBackend as an example, but events will require signals from the backend to the frontend, and some abstractions (like StorageArea) make a lot of sense whether or not things are split into two pieces, which sounds a lot like what you described with ResourceHandle. As a side note - I think it would be cool if we used more specific names than Backend and Frontened in the actual code, since which end is front and back is not always obvious nor always agreed upon by all observers. I like Proxy and Impl ok as name pairs, not sure if that's the same relationship you have in mind. I somewhat disagree regarding the terms frontend and backend being confusing. It seems to me that the backend is always further away from the user than the frontend. Same thing with client and server. That said, I've definitely heard complaints about terms like this before (on other projects), so I'm not married to the terms. The names I was planning to use were outlined in a design doc I sent to this list (http://docs.google.com/View?id=dhs4g97m_8cwths74m). Basically, I was planning to the term Backend, but the rest of the names are more descriptive. If you have another suggestion for Backend, I'd be happy to change it. I would have already, but the only other idea I had was server, and I think people find that term even more confusing. StorageRepository might be an ok name. As for Impl and Proxy, they are actually somewhat orthogonal to the frontend and backend. For example, if a script calls window.localStorage.setItem(foo, bar), the frontend in the render process will access the backend proxy which will send the message to the browser process where the backend implementation lives. The backend implementation will then access the EventManagerProxy which will distribute the events to the EventManagerImpl in all the render processes. In other words, Proxies are necessary anywhere messages originate. Jeremy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On Tue, May 26, 2009 at 9:42 PM, Maciej Stachowiak m...@apple.com wrote: On May 26, 2009, at 7:00 PM, John Abd-El-Malek wrote: This will work fine for appcache and localstorage, but isn't sufficient for workers since the same caller gets different objects depending on which process this is running in. This doesn't happen for appcache and localstorage. It's fine to use virtual methods when you actually need runtime polymorphism at the same call site. The point is not to tie yourself in a knot if there really is true polymorphism, just to avoid paying runtime penalties for anything that can actually be a compile-time decision. If it can't be, then so be it. Sounds good. I was a bit worried that we were needlessly adding a lot of complexity to the code, but you're definitely right that slow performance can be a death by a thousand cuts type thing. I'll give it a shot for DOM Storage, but it sounds like workers will need to still use polymorphism. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Local Storage naming (WAS Re: SharedWorkers alternate design)
On Wed, May 27, 2009 at 12:13 AM, Maciej Stachowiak m...@apple.com wrote: On May 27, 2009, at 12:00 AM, Jeremy Orlow wrote: On Tue, May 26, 2009 at 9:40 PM, Maciej Stachowiak m...@apple.com wrote: On May 26, 2009, at 6:11 PM, Jeremy Orlow wrote: Did you say partly because it's more complicated than just splitting one class (and only having 1-way sync communication)? If so, then we're still on the same page, because that's what I'll be doing as well. I was just using the StorageBackend as an example, but events will require signals from the backend to the frontend, and some abstractions (like StorageArea) make a lot of sense whether or not things are split into two pieces, which sounds a lot like what you described with ResourceHandle. As a side note - I think it would be cool if we used more specific names than Backend and Frontened in the actual code, since which end is front and back is not always obvious nor always agreed upon by all observers. I like Proxy and Impl ok as name pairs, not sure if that's the same relationship you have in mind. I somewhat disagree regarding the terms frontend and backend being confusing. It seems to me that the backend is always further away from the user than the frontend. An example of why I think these terms can be confusing: Which part of the style system would you guess is traditionally described as the back end? Hint: it's not the part further from the user. I'm glad we call it RenderStyle instead of StyleBackEnd in the code. :-) Point taken. Same thing with client and server. That said, I've definitely heard complaints about terms like this before (on other projects), so I'm not married to the terms. The names I was planning to use were outlined in a design doc I sent to this list (http://docs.google.com/View?id=dhs4g97m_8cwths74m). Basically, I was planning to the term Backend, but the rest of the names are more descriptive. If you have another suggestion for Backend, I'd be happy to change it. I would have already, but the only other idea I had was server, and I think people find that term even more confusing. StorageRepository might be an ok name. Something like StorageRepository or StorageDataStore (despite the repetition) might be good. I haven't thought deeply about specific uses of back end, but it's definitely something I am allergic to in general, as stated above. I'll try to come up with something better, but one of these should work if nothing else. As for Impl and Proxy, they are actually somewhat orthogonal to the frontend and backend. For example, if a script calls window.localStorage.setItem(foo, bar), the frontend in the render process will access the backend proxy which will send the message to the browser process where the backend implementation lives. The backend implementation will then access the EventManagerProxy which will distribute the events to the EventManagerImpl in all the render processes. In other words, Proxies are necessary anywhere messages originate. Thanks for clarifying. Regards, Maciej P.S. I hope all this design input isn't being too fussy. Working on a big project like WebKit is a constant battle against entropy, and we try hard to find good patterns and spread them as a counter. But I don't mean to make a huge deal out of this naming detail. Don't worry. I actually think naming is a pretty big deal since it makes a big difference in the readability of code and it's really hard to change a name in the future. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On Wed, May 27, 2009 at 3:37 PM, John Abd-El-Malek j...@google.com wrote: On Wed, May 27, 2009 at 12:00 AM, Jeremy Orlow jor...@chromium.orgwrote: On Tue, May 26, 2009 at 9:40 PM, Maciej Stachowiak m...@apple.com wrote: On May 26, 2009, at 6:11 PM, Jeremy Orlow wrote: Did you say partly because it's more complicated than just splitting one class (and only having 1-way sync communication)? If so, then we're still on the same page, because that's what I'll be doing as well. I was just using the StorageBackend as an example, but events will require signals from the backend to the frontend, and some abstractions (like StorageArea) make a lot of sense whether or not things are split into two pieces, which sounds a lot like what you described with ResourceHandle. As a side note - I think it would be cool if we used more specific names than Backend and Frontened in the actual code, since which end is front and back is not always obvious nor always agreed upon by all observers. I like Proxy and Impl ok as name pairs, not sure if that's the same relationship you have in mind. I somewhat disagree regarding the terms frontend and backend being confusing. It seems to me that the backend is always further away from the user than the frontend. Same thing with client and server. That said, I've definitely heard complaints about terms like this before (on other projects), so I'm not married to the terms. The names I was planning to use were outlined in a design doc I sent to this list (http://docs.google.com/View?id=dhs4g97m_8cwths74m). Basically, I was planning to the term Backend, but the rest of the names are more descriptive. If you have another suggestion for Backend, I'd be happy to change it. I would have already, but the only other idea I had was server, and I think people find that term even more confusing. StorageRepository might be an ok name. As for Impl and Proxy, they are actually somewhat orthogonal to the frontend and backend. For example, if a script calls window.localStorage.setItem(foo, bar), the frontend in the render process will access the backend proxy which will send the message to the browser process where the backend implementation lives. The backend implementation will then access the EventManagerProxy which will distribute the events to the EventManagerImpl in all the render processes. In other words, Proxies are necessary anywhere messages originate. Just as a data point: Chrome uses Proxy/Impl naming for a variety of classes (i.e. WebWorkerProxy/WebWorkerImpl, WebWorkerClientProxy/WebWorkerClientImpl, WebPluginProxy/WebPluginImpl, WebPluginDelegateProxy/WebPluginDelegateImpl). The code is also moving to X and XClient for the two-way API for feature X. If possible, it would be good to match these names for the sake of consistency. How about: StorageImpl (lives in the process that opens the database) StorageProxy (in multi-process browser, lives in the renderer process and notifies above) StorageClientImpl (receives event that value changed) StorageClientProxy (in multi-process browser, lives in the browser process and notifies above) Thanks for the pointers and suggestions. Unfortunately, in my experience, the distinction between client/server is even more confusing to developers than frontend/backend. In addition, the XClient naming scheme doesn't really fit into the design I've currently got in mind (which was documented in the design doc I've sent out a couple times) since there are a couple different classes that compose the frontend. So I'm not sure it'll really fit into my design here. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
I think it was pretty clear from the thread that X and XClient is prefered when you have 2 way communication. In some cases, you have X which is the interface, XImpl which is the implementation, and XProxy for a proxy. But yeahI think Foo and FooClient is the way to go with Impl and Proxy if you need to have 2 versions of each (which I think you do). J On Thu, May 28, 2009 at 3:14 PM, Michael Nordman micha...@google.comwrote: Doesn't sound like we have a consensus on naming yet? Many of the suggestions are workable to me. FooClient | FooFrontend | FooIntf | FooConsumer FooService | FooBackend | FooImpl | FooProvider I have a patch that is employing FooFrontend + FooBackend naming... i'd be happy to change to something else... or not. I don't like 'proxy' to indicate one side or the other, because as Jeremy said it doesn't indicate which side, there are proxies on both sides to communicate with the other. My top two picks... 1) FooFrontend + FooBackend 2) FooClient + FooService ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] AppCache class naming (WAS Re: SharedWorkers alternate design)
On Thu, May 28, 2009 at 4:32 PM, Michael Nordman micha...@google.comwrote: Can you think of a more specific way to describe the reationship than front and back or client and service? Does one of the Gang of Four Design Patterns apply? That can be a good resource for clear ways to describe class relationships, even fairly abstract ones. Nice suggestion... In my case Facade may be the most appropriate name for what i've been referring to as the 'frontend' interface. I'm endeavoring to provide a simplified interface (a facade) to a more complex system, the moving parts of which are not important to clients of the facade. Inside that Facade, Proxy may be the most appropriate for the messaging abstraction parts. ApplicationCacheFacade * uses ApplicationCacheSystemProxy ApplicationCacheSystem * uses ApplicationCacheFacadeProxy WDYT? I'm not really sure this is a Facade pattern. I think a good example of the facade pattern is the WebKit to WebCore relationship: a complex inner system that's made to be easy to use via the facade. Personally, I find the names less clear than Client/Server (or Backend/Frontend). What if we could come up with some more clear synonyms for Backend/Frontend? Another way to think about it is that the frontend is the seating area (or counter) of a resteraunt and the backend is the kitchen. What other metaphores along these lines would be similar? Maybe something about Storage vs Bindings (since the one half is about storing everything and the other is about hooking it into the resource loading)? I don't knowjust trying to brainstorm here. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] AppCache class naming (WAS Re: SharedWorkers alternate design)
HaKitchen/Counter were an attempt to push thinking in the right direction, not a real suggestion. Agree that this is a rat hole and it we need to move on. Still think Frontend/Backend is the clearest thing despite being used in a different manner in some other places and despite Client/Server(/Service) being used elsewhere. But Client/Service is my second choice. J On Fri, May 29, 2009 at 11:57 AM, Michael Nordman micha...@google.comwrote: I really have no strong opinions one way or the other (or the other), so long as its somewhat intelligible I'm good. Having said that Kitchen and Counter don't pass muster for me :) Bindings mean script bindings... not gonna overload that for this Intelligible options any of which work for me so far * FooFacade FooSystem * FooFrontend FooBackend * FooClient FooService We should wrap this rat hole up. On Fri, May 29, 2009 at 11:16 AM, Jeremy Orlowjor...@chromium.org wrote: On Thu, May 28, 2009 at 4:32 PM, Michael Nordman micha...@google.com wrote: Can you think of a more specific way to describe the reationship than front and back or client and service? Does one of the Gang of Four Design Patterns apply? That can be a good resource for clear ways to describe class relationships, even fairly abstract ones. Nice suggestion... In my case Facade may be the most appropriate name for what i've been referring to as the 'frontend' interface. I'm endeavoring to provide a simplified interface (a facade) to a more complex system, the moving parts of which are not important to clients of the facade. Inside that Facade, Proxy may be the most appropriate for the messaging abstraction parts. ApplicationCacheFacade * uses ApplicationCacheSystemProxy ApplicationCacheSystem * uses ApplicationCacheFacadeProxy WDYT? I'm not really sure this is a Facade pattern. I think a good example of the facade pattern is the WebKit to WebCore relationship: a complex inner system that's made to be easy to use via the facade. Personally, I find the names less clear than Client/Server (or Backend/Frontend). What if we could come up with some more clear synonyms for Backend/Frontend? Another way to think about it is that the frontend is the seating area (or counter) of a resteraunt and the backend is the kitchen. What other metaphores along these lines would be similar? Maybe something about Storage vs Bindings (since the one half is about storing everything and the other is about hooking it into the resource loading)? I don't knowjust trying to brainstorm here. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Security Origins
I have 2 questions about SecurityOrigins. First of all, in SecurityOrigin::databaseIdentifier() (in http://trac.webkit.org/browser/trunk/WebCore/page/SecurityOrigin.h) the following comment appears: Serialize the security origin for storage in the database. This format is deprecated and should be used only for compatibility with old databases; use toString() and createFromString() instead. This was done in http://trac.webkit.org/changeset/32597 Despite the comments in the change log, I don't fully understand what the intention here is. DatabaseTracker and LocalStorage still use databaseIdentifier() which makes sense since, unless I'm totally missing something, the toString() format produces file names that are invalid on most file systems. At the same time, databaseIdentifier omits some of the logic found in toString (which might be the cause of bugs like https://bugs.webkit.org/show_bug.cgi?id=20701 ...I haven't confirmed yet). So, maybe instead of databaseIdentifier() being deprecated, it should be updated to be more like a toString that uses file system safe characters? In addition, the creation of SecurityOrigin objects doesn't quite seem right. There are many places (like in DatabaseTracker) where security origins are created based on the file, port, and protocol. This is fine when all you're doing is .equals (which the HashMap's HashArg=SecurityOriginHash prarmeter does for you), but it seems like it could be inefficient (many SecurityOrigin objects describing the same origin) and could potentially lead to bugs (since not all of the properties are serialized during toString()/databaseIdentifier()). It's surprising to me that there isn't one central store of SecurityOrigin objects (maybe with weak references?) to eliminate the possibility of 2 SecurityOrigin objects describing the same origin. In general, I suppose I'm just trying to understand the thought behind SecurityOrigin objects and how they're used in the source code...because it doesn't seem very natural to me. Thanks, Jeremy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Security Origins
On Mon, Jun 1, 2009 at 11:30 PM, Adam Barth aba...@webkit.org wrote: On Mon, Jun 1, 2009 at 8:29 PM, Jeremy Orlow jor...@chromium.org wrote: If this is the only issue, the parsing code could work around it. There are 3 parts to the identifier: the protocol (should never have a _ in it, right?), the domain, and the port (once again, should never have a _). It seems as though the parsing code should look for the first _, the last _, and then assume everything in the middle is the domain. I don't know of any reason why a scheme can't have a _... If you'd like to change the parsing code to understand domains with a _ this way, I think that would be an improvement. Doesn't seem like a top priority, but maybe it's worth filing a low priority bug for it anyway. Although they are 2 somewhat distinct use cases and I see the possibility for misuse and bad assumptions, I'm not terribly worried about it. I think HTML 5 has notions of origin and effective script origin (or some such) that separate these two concepts. It might be worth syncing up our internal names with the spec to make these concepts more accessible to future developers. Agreed. Most of the new features use the simpler same origin policy which compares only the protocol, port, and domain. The effective script origin and the security around cookies are the more complex parts. I believe there's a fairly clean split between the two parts in the source code. I'll file a bug tomorrow regarding this opportunity for cleanup. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Security Origins
FYI: https://bugs.webkit.org/show_bug.cgi?id=26143 On Tue, Jun 2, 2009 at 12:45 AM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Jun 1, 2009 at 11:30 PM, Adam Barth aba...@webkit.org wrote: On Mon, Jun 1, 2009 at 8:29 PM, Jeremy Orlow jor...@chromium.org wrote: If this is the only issue, the parsing code could work around it. There are 3 parts to the identifier: the protocol (should never have a _ in it, right?), the domain, and the port (once again, should never have a _). It seems as though the parsing code should look for the first _, the last _, and then assume everything in the middle is the domain. I don't know of any reason why a scheme can't have a _... If you'd like to change the parsing code to understand domains with a _ this way, I think that would be an improvement. Doesn't seem like a top priority, but maybe it's worth filing a low priority bug for it anyway. Although they are 2 somewhat distinct use cases and I see the possibility for misuse and bad assumptions, I'm not terribly worried about it. I think HTML 5 has notions of origin and effective script origin (or some such) that separate these two concepts. It might be worth syncing up our internal names with the spec to make these concepts more accessible to future developers. Agreed. Most of the new features use the simpler same origin policy which compares only the protocol, port, and domain. The effective script origin and the security around cookies are the more complex parts. I believe there's a fairly clean split between the two parts in the source code. I'll file a bug tomorrow regarding this opportunity for cleanup. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] to reitveld or not to reitveld
For what it's worth, I definitely think a tool like reitveld would help the code review process. Inline comments and more context than the couple lines the diff provides are really, really helpful. On Fri, Jun 5, 2009 at 9:25 AM, Ojan Vafai o...@chromium.org wrote: Sorry in advance for the long email. I'm trying to be thorough. There's been a lot of discussion on #webkit about possibly using a code review tool like reitveld for webkit reviews. There's been various suggestions and a few misunderstandings, so it seems worth having a more formal discussion about this with the larger WebKit community. The things I'd like to assess here are: 1. Pros/Cons of using a system like reitveld. I listed some below. Please add any that I missed. 2. Whether the WebKit community is interested in pursuing something like this. 3. If there is interest, what is the best way to move forward. WHAT IS REITVELD It's a code review tool. Reitveld doesn't allow you to do anything that is impossible with the current review process, however, it makes the review process more efficient and less error-prone. As such, it makes it easier and less time-consuming to do good, thorough code reviews. The basic gist of reitveld is that it allows you to put comments inline and send them all in one chunk. Then it lets the reviewee easily respond to each comment individually and send all the responses in one chunk. EXAMPLE CHROMIUM PATCH http://codereview.chromium.org/119103 Note that you can view the patch in each version that was uploaded and that you can diff between versions. Also, if a comment was made in the version you were looking at, then you can see all the comments/responses. To see this nicely, under Delta from patch set in patch set 3, click on 2. That is where most of the comments in this review were made. For example, http://codereview.chromium.org/119103/diff2/14:27/29. You can see all the comments and responses along with the diff in the patch to see that the reviewer comments were implemented as intended. Keyboard shortcuts to try out: -n/p to switch between diff chunks -shift n/p to switch between comments -j/k to go to the next/previous file *Please don't actually click the Publish all my drafts button on the publish page as you'll be modifying a real code review.* Other things to try -try the side-by-side diff and the unified diff views -adding comments (double click) -replying to comments -go to the publish page (click the publish link or type m) Also note that the Committed URL is automatically added when the patch is committed and the reitveld issue is marked closed. So there isn't extra overhead in maintaining list of outstanding code reviews. HOW TO TRY IT OUT Here's the process for trying out reitveld with a webkit patch. The current workflow is a bit janky, but some scripting and some simple reitveld fixes would make this a lot more natural and automated (e.g. chromium uses commandline gcl upload to put up a new patch). 1. Find a non-git patch 2. Go to http://codereview.chromium.org/new 3. Login with a Google account (e.g. any gmail or Google search account) 4. On that page, type in a subject and paste in the URL to the patch in the URL field. 5. Click Create Issue There's a couple apparent bugs that are easily fixable: 1. The ChangeLog files don't get downloaded correct, so the diffs don't work. This is an AppEngine problem that Chromium works around with the gcl upload script. 2. With an old patch there are often diff chunk mistmatches, which breaks the side-by-side diff view (you can use the unified diff in those cases). PROS For the reviewer: -easier to write thorough review comments since adding comments is so light-weight -easier to make sure that all review comments actually got implemented For the reviewee: -easier to see which line the reviewer's comment addresses -easier to make sure you've completed all the reviewer's comments (you can mark them as done in reitveld as you go) For everyone: -efficient keyboard navigation (e.g. j/k to navigation between diff chunks and n/p to navigate between files -easier to follow the progression of a code review and see what changed over the course of the review -shows image files, so you can see before/after before commit CONS (most of these are easy to fix/improve) -There's no pretty printed view of all the files in the patch at once that lets you insert comments -The UI is a bit cluttered -It takes using it for a couple patches before you're totally comfortable with it -Currently doesn't work with diffs generated by git -Reitveld's current implementation requires running on AppEngine -A couple issues with reitveld on appengine that Chromium uses a script to workaround (line-endings differences and large files like ChangeLogs don't upload correclty). PATH FORWARD As far as reitveld versus another code review tool, I don't have strong opinions. I hear
Re: [webkit-dev] Expected behavior of Mutex.lock()
I actually had exact the same question (but never got around to asking it). Given that pthreads' implementation is more strict, it'd seem like mutexes are not supposed to be reentrant. Maybe the windows version should ASSERT on reentrancy when in debug mode? On Tue, Jun 9, 2009 at 11:09 AM, Drew Wilson atwil...@google.com wrote: Any insights here? I'd be happy to add some documentation to Mutex if someone can verify what the intended behavior is... -atw sending emails to webkit-dev during WWDC is probably futile, I know :) On Sat, Jun 6, 2009 at 8:57 AM, Drew Wilson atwil...@google.com wrote: I can't seem to find any documentation as to what the expected behavior of Mutex.lock() is with regard to calling lock() recursively on the same thread. Looking at the pthreads implementation, it appears that when we create the mutex we pass null as the attributes, which gives us the default behavior (not re-entrant). The Windows implementation uses EnterCriticalSection which *is* re-entrant. I'm assuming that the pthreads implementation is the correct one (calling Mutex.lock() twice on the same mutex on a single thread should deadlock the thread) but I wanted to verify this since the implementations seem to vary. -atw ___ 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] Expected behavior of Mutex.lock()
Agreed the ASSERT needn't be Windows only. It's probably better to ASSERT rather than deadlock on platforms without reentrant implementations. :-) I'll file a bug for this (and might just fix it) in a couple days if there are no more comments. J On Thu, Jun 11, 2009 at 10:39 AM, Dmitry Titov dim...@chromium.org wrote: Then perhaps all implementations could ASSERT in debug on mutex reentrancy to help discover where differences in behavior are accidentally 'used' (a stuck thread may sometimes mask some other issues). It's not good to have this kind of differences in 'cross-platform' code, sooner or later it'll cause very cryptic bugs, especially since developers with Windows background take reentrancy of critical section for granted. Dmitry On Tue, Jun 9, 2009 at 11:34 AM, Jeremy Orlow jor...@chromium.org wrote: I actually had exact the same question (but never got around to asking it). Given that pthreads' implementation is more strict, it'd seem like mutexes are not supposed to be reentrant. Maybe the windows version should ASSERT on reentrancy when in debug mode? On Tue, Jun 9, 2009 at 11:09 AM, Drew Wilson atwil...@google.com wrote: Any insights here? I'd be happy to add some documentation to Mutex if someone can verify what the intended behavior is... -atw sending emails to webkit-dev during WWDC is probably futile, I know :) On Sat, Jun 6, 2009 at 8:57 AM, Drew Wilson atwil...@google.com wrote: I can't seem to find any documentation as to what the expected behavior of Mutex.lock() is with regard to calling lock() recursively on the same thread. Looking at the pthreads implementation, it appears that when we create the mutex we pass null as the attributes, which gives us the default behavior (not re-entrant). The Windows implementation uses EnterCriticalSection which *is* re-entrant. I'm assuming that the pthreads implementation is the correct one (calling Mutex.lock() twice on the same mutex on a single thread should deadlock the thread) but I wanted to verify this since the implementations seem to vary. -atw ___ 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] A Javascript Programming Environment for Safari 4
On Wed, Jun 10, 2009 at 7:22 PM, David Goehrig d...@nexttolast.com wrote:
Hello Webkitties,
Let me say, congratulations on getting so close to having real HTML5
support. While there are still some rough edges, Webkit has been making
some huge strides towards making the web a nice place to program. In the
spirit of showing off what can be done with the right tools, I've released a
bit of code that currently only runs under Safari 4.
I'm curious to know what APIs you're using that aren't working correctly in
Google Chrome.
Also, I know it's not done, but here's a few suggestions:
* The white boarder is a bit distracting. You probably want to do something
like body { margin: 0px } in CSS?
* The direction stuff moves on the canvas while scrolling should be
reversed.
Pretty cool for so few lines of code though!
It is a live object programming environment inspired by Randal Smith and
David Ungar's paper Programming as an Experience: The Inspiration for
Self. Like the Self environment, I've built a slot based object editing
system, just with a bit more drag drop support, HTML5 canvas integration,
and a classy object traits style programming model.
If you'd like to see what is possible in Safari 4 in about 3 days:
http://www.dloh.org/
The full source is available under the GPL3 license from github.com:
git clone git://github.com/cthulhuology/Phos.git
There's a set of tutorials available on the webapp, as well as, a series of
video tutorials on youtube. You can find the lot of them:
http://blog.dloh.org/
I'm going to add collaborative object editing support to the environment
this weekend, and should have offline and remote object storage done around
the same time.
Great work for making this sort of app possible,
David J. Goehrig
PS.
For those who are curious, the code base is small, ~588 Lines of code in
172 or so functions. Between 100-200 lines of code are there just to work
around issues with Javascript or API wonkiness. The meat of the application
is ~200 lines of code in 41 functions that provides support for Text,
Graphics, Video, and Sound widgets. The base 385 lines, consists of a
multipurpose library that I've used on two javascript projects. (The other
is NewScript, a Postscript meets Javascript language with an Intel native
compiler implemented in 100 or so lines of javascript).
--
-=-=-=-=-=-=-=-=-=-=- http://blog.dloh.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] to reitveld or not to reitveld
On Thu, Jun 11, 2009 at 4:50 PM, Joe Mason joe.ma...@torchmobile.comwrote: Mark Rowe wrote: On 2009-06-11, at 15:16, Ojan Vafai wrote: On Sat, Jun 6, 2009 at 7:14 PM, Ojan Vafai o...@google.com mailto: o...@google.com wrote: On Sun, Jun 7, 2009 at 7:51 AM, Mark Rowe mr...@apple.com mailto:mr...@apple.com wrote: There are also concerns about access to the data store of the application, backup procedures, etc. Our existing servers are well understood in this regard. We've also found in the past that having services spread across different systems causes confusion when something goes wrong, for whatever reason, as it's not clear who to contact to address the problem. For what it's worth, we've had next to zero maintenance effort go into keeping rietveld running on appengine. As far as I know, it's been pretty much stable and problem free. But I don't actually maintain it, so I can't say that for sure. :) It seems to me that all the issues raised with using reitveld are solvable. Assuming you all are OK with doing this iteratively instead of needing all the issues to be resolved on day one, I think we can probably start taking concrete steps forward. Given what has been said so far I'm still not clear why Rietvald is a better option than Review Board. Well, I haven't heard anything concrete on why Review Board is better than rveld, either. All I've seen are some posts saying, You know, Review Board exists too. Is the UI better? Is the architecture better? Is the design very different? Is it easier to integrate with git? Exactly how much work is involved in hosting each of these solutions? The only thing concrete I've seen is that Review Board is self-hosting, while rveld is tied to AppEngine. ...and there's some that you could run rietveld without AppEngine infastructure if necessary. FWIW, another project I (used to) work on tried Review Board out about a year ago. We found it to be pretty clunky, so we continued just doing code reviews via diffs in email. Maybe it's improved since then. Either way, I believe the team is now using Rietveld for large reviews. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] to reitveld or not to reitveld
On Thu, Jun 11, 2009 at 5:19 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Jun 11, 2009 at 4:50 PM, Joe Mason joe.ma...@torchmobile.comwrote: Mark Rowe wrote: On 2009-06-11, at 15:16, Ojan Vafai wrote: On Sat, Jun 6, 2009 at 7:14 PM, Ojan Vafai o...@google.com mailto: o...@google.com wrote: On Sun, Jun 7, 2009 at 7:51 AM, Mark Rowe mr...@apple.com mailto:mr...@apple.com wrote: There are also concerns about access to the data store of the application, backup procedures, etc. Our existing servers are well understood in this regard. We've also found in the past that having services spread across different systems causes confusion when something goes wrong, for whatever reason, as it's not clear who to contact to address the problem. For what it's worth, we've had next to zero maintenance effort go into keeping rietveld running on appengine. As far as I know, it's been pretty much stable and problem free. But I don't actually maintain it, so I can't say that for sure. :) It seems to me that all the issues raised with using reitveld are solvable. Assuming you all are OK with doing this iteratively instead of needing all the issues to be resolved on day one, I think we can probably start taking concrete steps forward. Given what has been said so far I'm still not clear why Rietvald is a better option than Review Board. Well, I haven't heard anything concrete on why Review Board is better than rveld, either. All I've seen are some posts saying, You know, Review Board exists too. Is the UI better? Is the architecture better? Is the design very different? Is it easier to integrate with git? Exactly how much work is involved in hosting each of these solutions? The only thing concrete I've seen is that Review Board is self-hosting, while rveld is tied to AppEngine. ...and there's some that you could run rietveld without AppEngine infastructure if necessary. er...there's there's some _evidence_ that you could run rietveld without AppEngine infastructure if necessary. (referring back to Ojan's comment) FWIW, another project I (used to) work on tried Review Board out about a year ago. We found it to be pretty clunky, so we continued just doing code reviews via diffs in email. Maybe it's improved since then. Either way, I believe the team is now using Rietveld for large reviews. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] about webkit's license in chrome
The license is assigned on a per-file basis and can be found at the top of the file. 2009/6/12 David Jones ds...@163.com well, is there a doc about that? or, could you describe it more detailedly ? I want to know which part is under BSD, LGPL and so on. I don't find a license illustration in webkit's src. On Thu, Jun 11, 2009 at 10:44:25PM -0700, Peter Kasting wrote: 2009/6/11 David Jones ds...@163.com As listed in http://code.google.com/chromium/terms.html#3rdparty , there're three different licenses of webkit in chrome: BSD http://www.opensource.org/licenses/bsd-license.php/LGPL 2/LGPL 21http://opensource.org/licenses/lgpl-2.1.php Why? For the same reason the Mozilla code lists three licenses: because the code is tri-licensed. It is offered simultaneously under three different licenses. Technically, that is not true. While (most of) Mozilla code is effectively tri-licensed, i.e released under the terms of the three licences, WebKit code is partly licensed under each one, i.e. parts are under 2-clause BSD, parts under 3-clause BSD, and parts under LGPL 2 or 2.1. Mike -- 网易全新推出企业邮箱 http://qiye.163.com/?ft=2 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Review states
Rietveld doesn't really support any flags, right? It seems like they could be added in without too much effort though. Mondrian (its closed source parent) does. J On Wed, Jun 17, 2009 at 11:13 AM, Eric Seidel e...@webkit.org wrote: It would appear bugzilla is too lame to support changing flag values +/-/? are all we get. :( https://bugs.webkit.org/editflagtypes.cgi (only accessible to bugzilla users with edit privilages). Maybe the solution is a different review tool instead of adding flags to attachments on the bug. :( I don't think Rietveld supports any sort of flags either though. I've not looked at review board. -eric On Wed, Jun 17, 2009 at 8:14 AM, Maciej Stachowiakm...@apple.com wrote: On Jun 17, 2009, at 1:39 AM, Mark Rowe wrote: On 2009-06-17, at 00:41, Eric Seidel wrote: I propose altering our bugzilla setup to have the following review states (effectively adding a 4th state): review: REQUESTED DENIED APPROVED WITH MODIFICATIONS APPROVED I think DENIED could also do with having a hard and soft state. One to indicate that the approach is completely wrong, and another to indicate that the approach is sound but it just needs another round of improvements and review. Also, does Bugzilla support custom states for flags? ISTR that it only allows the three states and provides no means of changing their names. If I were to name the states, then instead of review? / review- / review+, I would have something like: Review Rejected (for the rare case where the concept of a patch tries to do is completely wrong; often in this case the bug will also be INVALID) Revise and Resubmit Commit with Changes (probably this should only be used when the patch submitter is a commiter) Commit If flags won't cut it, we could try to teach bugzilla to use something else as the basis for review, such as keywords or the status whiteboard. I would also like to change the names of the bug states and resolutions; I don't know how much we are constrained by bugzilla here. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] MIPS port problem - cti_op_put_by_id slow case problem
IANAL (and correct me if I'm wrong), but 1) Parts of WebKit are licensed under the LGPL 2) Even if you're not modifying (or copying code from) files licensed under the LGPL, any files linked to those LGPL files are governed by the LGPL 3) Presumably you're going to distribute binaries that include your modified version of WebKit 4) And thus aren't you compelled to release the source code for anything linked to any LGPL whenever 3 happens? If so, why not just develop in the open? J On Wed, Jun 17, 2009 at 1:56 PM, Toshiyasu Morita tm_web...@yahoo.comwrote: --- On *Wed, 6/17/09, Geoffrey Garen gga...@apple.com* wrote: I'm not really interested in helping with the dubiously legal task of taking JavaScriptCore, which is an OpenSource library, and turning it into a closed, proprietary library. I'm not sure where this weird idea of developing a closed proprietary library came from. I have never mentioned anything about developing a closed proprietary library. My client is a hardware company. It produces consumer devices. They have been using GNU software for a long time. Their current website has a support download page where you can download the GNU source code used in all their released products. Toshi ___ 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] Changes to prepare-ChangeLog
On Fri, Jul 3, 2009 at 10:24 AM, Peter Kasting pkast...@google.com wrote: Since this seems to have become the new bikeshed, I'll chime in with my color preference: Reviewed by John Smith (jsm...@webkit.org) https://bugs.webkit.org/show_bug.cgi?id=123456 Fix WebKit being not awesome enough. Make five files more awesome. FWIW, I agree with those who desire to ditch the ChangeLog. WebKit is the only project I've worked on that does such a thing, and I have never gotten any benefit out of it, while I've gotten lots of headache (merge conflicts especially). On Chromium, patches are given a detailed ChangeLog-esque description which is visible in the review tool and becomes the commit log message as well (which links back to the review URL, and is also auto-pasted into the original bug report). This way from any of (bug system, commit logs, review system) you can find information about a particular patch or search for patches matching some comment. This turns out to work quite well in practice. In WebKit I try to give my patches these sorts of comments when I post them for review, but duplicating info between the ChangeLog and the review comments always makes me write less than I otherwise would, and review comments tend to get buried in the sea of noise from bugzilla. I agree that the ChangeLog really is duplicate information and generally a pain to update. I know that there are some people who really like them. Why not fill them in automatically? Just have a tool that once a night/hour/checkin generates entries for the new checkins and puts it somewhere on the web or checks it in. I know one of the concerns was reviews. What I do anyway is copy the ChangeLog description into the optional long description field when posting the patch, why not do that? Maybe it'd even be easy to display that somewhere on the review UI, but otherwise it seems fine to just open the review in another tab in case you need to refer back to it. It seems like the ChangeLog is just a work-around for a lack of tools. And it seems like it wouldn't be too hard to make the tools we've got better. (And yes, I'll even help out if that's the direction everyone chooses to take. :-) J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ChangeLog
To be more clear: Rietveld + gcl (the way Chromium does reviews/checkins) has you specify a group of files which is called a change list. Part of each change list is a description. Reviewers use and critique this description, which is much like what's done with the ChangeLog. Nothing lists out the modified functions like in your ChangeLog, but I guess that's just not something people commonly need. (And this could still be done by an automated script or a new search tool if that'd still be helpful to people.) If you haven't taken a look at http://codereview.chromium.org I strongly suggest you do so. Rietveld + gcl really do make life easier for us on Chromium--especially if you're a reviewer. (It would also solve the 3 lines of context issue that Julie brought up the other day.) J On Fri, Jul 3, 2009 at 10:59 AM, Peter Kasting pkast...@google.com wrote: On Fri, Jul 3, 2009 at 10:55 AM, Darin Adler da...@apple.com wrote: It's backwards to say that the ChangeLog is a workaround for lack of tools. Some day we may see a tool that works so well that we’d be willing to forgo change logs, but we need to see that tool in action first to see that it functions so well it obviates the need for ChangeLog. I once again suggest Rietveld, which has been suggested here before. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ChangeLog
On Fri, Jul 3, 2009 at 12:29 PM, Darin Adler da...@apple.com wrote: On Jul 3, 2009, at 12:04 PM, Jeremy Orlow wrote: Nothing lists out the modified functions like in your ChangeLog, but I guess that's just not something people commonly need. I often search for old relevant changes by searching for function names. At least once a week for the last 5 years. I meant to say I'm guessing not I guess. In hindsight, it was a stupid thing to say. :-) I stand by the rest of my email, though. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Git Familiarity (was ChangeLog)
On Sun, Jul 5, 2009 at 10:22 PM, Justin Haygood jhayg...@reaktix.comwrote: - Original Message - From: Benjamin Meyer b...@meyerhome.net To: WebKit Development webkit-dev@lists.webkit.org Sent: Sunday, July 05, 2009 11:25 PM Subject: Re: [webkit-dev] Git Familiarity (was ChangeLog) At least on Windows I use mysygit myself ( http://code.google.com/p/msysgit/ ) From the project description: Historically, Git on Windows was only officially supported using Cygwin. To help make a native Windows version, this project was started, based on the fork. Still has the following problems: 1. No Windows integrated UI. Windows is very UI driven, and all of the development tools are UI based. Why should I open up a command line to do VCS stuff? I don't have to open up a command line now. 2. No Visual Studio integration. Subversion not only has TortoiseSVN, but there's AnkhSVN that lets you manage it entirely inside Visual Studio. The official instructions for getting and building WebKit involve things run from the command prompt. I agree that there are plenty of Windows based developers who would not be comfortable using a command line, but I find it hard to believe that there are many hacking on WebKit. And, if they are, they're probably savvy enough to write MSVC++ macros. For what it's worth, I support switching to git. It certainly will be painful for some, but I think it'll be a win before long. That said, I also think Maciej is right and that there are some bigger fish to fry at the moment. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to write a hello world example in Webkit Gtk?
Please use webkit-h...@lists.webkit.org On Mon, Jul 6, 2009 at 6:36 PM, deuxliquid deuxliq...@yahoo.com wrote: Hi all, I have just installed Gtk-2.16.0 on my computer. Next, I must install webkit that base Gtk but I am not able. It seems Webkit is too big(?) so that it has number of errors. I wonder if there is a Gtk that has already integrated webkit? Because I know Qt has also itegerated Webkit in it. Can anybody help me to write a small example like hello world in Gtk Webkit? Thank you in advance! Hai -- Lướt web nhanh hơn http://us.lrd.yahoo.com/_ylc=X3oDMTFnYXY0dG83BHRtX2RtZWNoA1RleHQgTGluawR0bV9sbmsDVTExMDM0NjgEdG1fbmV0A1lhaG9vIQ--/SIG=11ka86nha/**http%3A//downloads.yahoo.com/vn/internetexplorer/ Internet Explorer 8 tối ưu hóa cho Yahoo!, tự động khởi động 2 trang bạn thích mỗi lần mở trình duyệt. Tải IE8 tại đây! (Miễn phí)http://us.lrd.yahoo.com/_ylc=X3oDMTFnYXY0dG83BHRtX2RtZWNoA1RleHQgTGluawR0bV9sbmsDVTExMDM0NjgEdG1fbmV0A1lhaG9vIQ--/SIG=11ka86nha/**http%3A//downloads.yahoo.com/vn/internetexplorer/ ___ 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] any progress on GObject/C DOM binding? (#16401)
WebKit has a high bar for code reviews. It's rarely possible to do a high quality code review on huge patches. This is one of the reasons developing in the open (not writing all the code and then trying to get it committed) is advantageous. I don't really see why such bindings (as cool as they are) are worth lowering the bar for submissions. Hopefully someone can split the patch up. J On Wed, Jul 8, 2009 at 9:06 AM, Gour g...@gour-nitai.com wrote: Hi! Few days ago I found out about Pyjamas(-Desktop) project and became ecstatic upon the prospect of being able to use the same Python code to run both desktop and web app in a browser. However, soon I've came to know there are some showstopper preventing users fully utilize this project or forcing them to use patched version of webkit. Today I was browsing the bugzilla and it seems that the situation is summarized as: The reviewer(s) have said: - The patch must be broken up into smaller pieces before being reviewed further. I think the important take-away here is that no one has stated that the patch may never be landed, just that it needs to be broken up, reviewed and landed in pieces. I'm not sure there's much more to say at this point until you (or someone else) can find more time to work on breaking up the patch. I left my comment there, but here I'm appealing (as end-user) if some progress can be made so that we can get full DOM binding and having opportunity to enjoy in whatever pyjamas project is offering to Python coders. (Un)fortunately I do not speak Java and prefer writing in Python vs. different JS Ajax frameworks. Let's be happy that someone wrote the code and don't put policies over it. Hoping that DOM bindings will escape from its stalemate position. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ___ 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] Please welcome GYP to the our dysfunctional build family
This makes me very, very, very happy. :-) On Thu, Jul 9, 2009 at 9:23 PM, Dimitri Glazkov dglaz...@chromium.orgwrote: Dear WebKiteurs, In our persisting quest to be more like a common WebKit port, we have added Chromium build files to the tree this afternoon. These files are WebCore/WebCore.gypi and JavaScriptCore/JavaScriptCore.gypi and they are the GYP include files. As you may know, we use GYP (http://code.google.com/p/gyp) for generating MSVC, XCode, Scons, and even Make projects for Chromium. We are rather fond of GYP. Perhaps it is because it allows us to maintain one set of project files for all three Chromium platforms; or maybe because it lets us to do things like WebCore.gypi, where we can just mindlessly add all project files to the list and then use various neat GYP filtering facilities to narrow them down to sets that are relevant for specific builds; or maybe because it easifies creating cross-platform and cross-build-system targets, actions, and rules; or maybe because we just love saying Gyp! I don't truthfully know. What I do know is that starting now, we'd love for you to remember WebCore.gypi and JavaScriptCore.gypi when you are adding or removing files from WebCore or JavaScriptCore. Thanks to the power of GYP, you don't have worry whether this file will be used by Chromium: the rule is that if there's a project file change, it applies to the *.gypi files. The format is very simple and intuitive, a simple Python/JSONey list+dict. Thank you for your attention, men and women of WebKit. :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] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family)
On Fri, Jul 10, 2009 at 1:14 PM, Kevin Ollivier kev...@theolliviers.comwrote: Hi David, On Jul 10, 2009, at 11:06 AM, David Kilzer wrote: So, does anyone think this would be a bad idea, or have any alternate suggestions on how to improve things? What about adding support for waf to gyp? If we're talking about Chromium, waf is much faster for building WebKit than scons is, so yeah, I would say adding the ability to use it instead of scons is a no-brainer. As for wx, while I'm open to the idea of using gyp to help others out or simplify matters for the core devs, for us I'm pretty sure it will mostly just be one more added layer to our build system. I've been using Bakefile for years now and while I thought the idea was great at first, I've found it mostly a pain to work with. Some of that is due to Bakefile itself, of course (like the latest bug...), but a lot of it is just the general approach and issues inherent with adding one more tool to the toolchain. Even though there's some sort of meta-tool generating the build projects, it only reduces, not removes, the need to understand and deal with the native project formats it outputs. Also, since the meta-tool can have bugs or missing features too, there's an additional point of failure added, and also added work in terms of maintaining the build system. Plus, any time you want to add a feature, you should look into how to implement it in the various formats that gyp supports to avoid hacks, a process which can sometimes require pretty creative solutions for less capable build tools. And there's also the fact that, if wx uses gyp, people are going to start asking for support for their favorite project format, which is just one more thing to deal with. In short, I think I've just come to be soured on the approach in general. I think I've come to agree with the point that the waf site makes about domain-specific languages not being a good idea for build systems, and when you use a tool like Bakefile or gyp, you not only need to become familiar with that tool's project file language, but also to some level with the formats of the project files that it outputs in order to debug or add new capabilities. With waf, all I ever really need to know is Python, which I already know, and the waf APIs, which I'm learning but for the most part have been pretty simple and straightforward to work with. The bottom line for me is that anything that has me spending less time on maintaining the build system and more on the actual product is a good thing in my book. ;-) Your argument makes sense if WebKit is only built for one platform/build-system. Unfortunately it's not. So the question is whether it's easier to maintain lots of different build files or whether it's easier to maintain one file that's perhaps a bit more abstract + the tool that interprets it. I agree that working directly in the project file for your platform is easier IF you're only developing for one platform. But once you start maintaining more than one project file, I think GYP is a big win. While we hope that others will update our GYPI file when they add/remove files, our build depends on it...so we'll definitely be keeping it in sync. So I think the question then becomes whether it's easier for you to maintain your new build format, or whether it's easier to make it a target for GYP. I honestly don't know what the answer is, but I think it's worth taking a closer look at GYP. J Thanks, Kevin The only format I'm not sure if we could automate reliably would be the XCode format (at least, on non-Mac machines), because IIUC we'd need some sort of parser for it, but Apple is the only port maintaining those directly IIUC, as now Chromium will be using GYP to update their XCode projects. If you hand-edit Xcode project files enough times you start to understand them, but you also may go insane in the process. I don't know that you have to write a full parser for it, but there is some non-trivial, minimal structure you have to understand to update the file properly. So even if we couldn't solve the XCode issue, that would drop it to updating two locations tops. I count 6 build systems in use currently (SCons support was added and removed within the last year): - Apple's Xcode - Apple's vcproj (also used by at least one other Windows port) - wx Bakefile (which will be replaced by waf soon) - Qt Qmake - GTK GNUMakefile - Google's gyp (added recently) Are any of the other ports going to switch to generating their build files using gyp? Dave - Original Message From: Kevin Ollivier kev...@theolliviers.com To: Dimitri Glazkov dglaz...@chromium.org Cc: Mark Mentovai m...@chromium.org; WebKit Development webkit-dev@lists.webkit.org Sent: Friday, July 10, 2009 8:52:57 AM Subject: [webkit-dev] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family) Hi Dimitri and
Re: [webkit-dev] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family)
On Fri, Jul 10, 2009 at 6:26 PM, Kevin Ollivier kev...@theolliviers.comwrote: Hi Jeremy, On Jul 10, 2009, at 3:03 PM, Jeremy Orlow wrote: [snip] Your argument makes sense if WebKit is only built for one platform/build-system. Unfortunately it's not. So the question is whether it's easier to maintain lots of different build files or whether it's easier to maintain one file that's perhaps a bit more abstract + the tool that interprets it. I agree that working directly in the project file for your platform is easier IF you're only developing for one platform. But once you start maintaining more than one project file, I think GYP is a big win. While we hope that others will update our GYPI file when they add/remove files, our build depends on it...so we'll definitely be keeping it in sync. So I think the question then becomes whether it's easier for you to maintain your new build format, or whether it's easier to make it a target for GYP. I honestly don't know what the answer is, but I think it's worth taking a closer look at GYP. Actually, the big question in regards to having GYP reduce overall project maintenance is whether or not the other ports will adopt GYP. If the answer is yes, then it would be more compelling for wx to do so as well, assuming of course that someone implements a waf backend so that we can. :-) If the answer is no, though, then GYP is not reducing the amount of project maintenance work for any port other than Chromium, in which case there will still be 6 build systems (still 5 even if wx were to switch) and the problem I originally posed in this thread will still be an issue. In that case, the only way to really reduce the maintenance work of adding / removing files would again be to adopt a script like the one I suggested earlier. You're right. The burden of updating the GYPI file is less than the others, but it's still another file you need to change. But note that the maintainers of each project/platform/etc define which files to exclude. This is different from the other build systems where the person updating the file needs to decide whether it should go into the build or whether it should only be built with certain flags. Speaking of which, with waf / Python I've actually almost completely automated the generation of the list of include dirs for my build projects based on the source files, so that I'm not maintaining them by hand anymore except for a few exceptions. And thinking about it, I bet I can even mostly automate the list of source files too, by having it grab all the .cpp files in the common dirs and special subdirs like curl and wx, then having some include / exclude filters to deal with a few special cases. :-) The question will be the performance hit, but at least with the includes it's not even noticeable, and I could always look into caching and changing only when you do an svn up or svn add/remove. I suggest you take a look at GYP. Much of what you're talking about it already does. That's the sort of flexibility and ability to quickly experiment and automate that scripts offer, and I suspect I will really miss that if I switch back to something like Bakefile / GYP. Of course you're going to be able to experiment easier with something you wrote yourself. That said, the generator for scons is only 780 lines of code including a couple hundred of templates...so it doesn't seem like it'd be _that_ hard to figure it out. I'm not necessarily saying you guys should be using GYP, but I really think you should take a closer look at it. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Please welcome GYP to the our dysfunctional build family
On Sun, Jul 12, 2009 at 5:38 AM, Adam Treat tr...@kde.org wrote: On Friday 10 July 2009 12:23:50 am Dimitri Glazkov wrote: Dear WebKiteurs, In our persisting quest to be more like a common WebKit port, we have added Chromium build files to the tree this afternoon. These files are WebCore/WebCore.gypi and JavaScriptCore/JavaScriptCore.gypi and they are the GYP include files. As you may know, we use GYP (http://code.google.com/p/gyp) for generating MSVC, XCode, Scons, and even Make projects for Chromium. We are rather fond of GYP. Perhaps it is because it allows us to maintain one set of project files for all three Chromium platforms; Gyp sounds remarkably similar to CMake to me. I've never heard of Gyp before so I don't know much more about it than what you've said in this email, but CMake has been around for quite sometime and is in very wide use in the Open Source community. Can you say what prompts the use of Gyp over a tool like CMake? From a quick glance at cmake's website, it seems that it's a build system and not a project file generator. I think it was pretty important to us to generate project files so that you can use the full power of each platform's IDE and toolchain. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ENABLE_FORM_VALIDATION
On Mon, Jul 13, 2009 at 11:40 AM, David Hyatt hy...@apple.com wrote: On Jul 13, 2009, at 12:52 PM, Peter Kasting wrote: On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt hy...@apple.com wrote: I agree. We should formalize this as policy too in my opinion. Maybe something time-based, e.g., if you have an implementation of a new Web technology that is going to take (1month?) to implement, then the feature should be landed inside ENABLE ifdefs (that can then be removed when the feature is sufficiently far along). For Chromium this kind of time frame can be problematic, since there's pretty much no guarantee of when a WebKit trunk build could be shipped as (eventually) a stable Chromium/Google Chrome release. Even having an incomplete feature in the tree a few days can result in the incomplete feature getting shipped to web authors. The way to ship ToT (in my opinion) is to cut a branch, watch ToT for any regressions from recent work, merge those fixes into the branch, and then turn off anything that is in-progress on the branch. Expecting ToT to actually be shippable all the time is not very practical. Realistically people will always be causing occasional regressions from bug fixes and feature work. Branches are the way to stabilize from some known point. I agree, but I also agree with Peter's heuristic for when things should be behind a flag. Regressions can always happen, but if you're knowingly introducing something that's half-baked it really seems like it should be behind a flag. Note also that Chromium's dev channel releases are pretty much weekly, so cutting a branch for those is not practical. Some web developers do use WebKit's nightly builds and Chromium's dev channel, so keeping things relatively stable (with not much cost...flags are easy to add) seems like the right way to go. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ENABLE_FORM_VALIDATION
On Mon, Jul 13, 2009 at 11:57 AM, David Hyatt hy...@apple.com wrote: On Jul 13, 2009, at 1:52 PM, Jeremy Orlow wrote: On Mon, Jul 13, 2009 at 11:40 AM, David Hyatt hy...@apple.com wrote: On Jul 13, 2009, at 12:52 PM, Peter Kasting wrote: On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt hy...@apple.com wrote: I agree. We should formalize this as policy too in my opinion. Maybe something time-based, e.g., if you have an implementation of a new Web technology that is going to take (1month?) to implement, then the feature should be landed inside ENABLE ifdefs (that can then be removed when the feature is sufficiently far along). For Chromium this kind of time frame can be problematic, since there's pretty much no guarantee of when a WebKit trunk build could be shipped as (eventually) a stable Chromium/Google Chrome release. Even having an incomplete feature in the tree a few days can result in the incomplete feature getting shipped to web authors. The way to ship ToT (in my opinion) is to cut a branch, watch ToT for any regressions from recent work, merge those fixes into the branch, and then turn off anything that is in-progress on the branch. Expecting ToT to actually be shippable all the time is not very practical. Realistically people will always be causing occasional regressions from bug fixes and feature work. Branches are the way to stabilize from some known point. I agree, but I also agree with Peter's heuristic for when things should be behind a flag. Regressions can always happen, but if you're knowingly introducing something that's half-baked it really seems like it should be behind a flag. I agree with that. I'm just asserting that some reasonable time limit before requiring ifdefs is ok. If a feature only takes 1-2 weeks to land, I think it's total overkill to put it inside an ifdef. Any cut branch should take long enough to stabilize that it could merge the rest of the feature in anyway. Hm. Now that I think about it, I'm mixing up breaking existing behavior and adding new features which are in flux. In the former case, it should always be behind a flag, right? But yeah, for the latter case, I guess 1-2 weeks seems reasonable to me. If you're ever cutting a branch off ToT and shipping it as a full-blown release with less than 2 weeks turnaround, you're doing it wrong in my opinion. I think we can all agree with that. :-) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Haiku + GYP (WAS: Build File Maintenance)
I'm adding a bunch of the GYP experts to this thread and re-naming it for sanity's sake. :-) On Wed, Jul 15, 2009 at 11:20 PM, Maciej Stachowiak m...@apple.com wrote: If you're willing to give it a shot, then that sounds like a fine idea. - Maciej On Jul 15, 2009, at 10:51 PM, Ryan Leavengood wrote: On Mon, Jul 13, 2009 at 4:56 PM, Maciej Stachowiakm...@apple.com wrote: One belated comment on this topic. It would be neat if some port agreed to be the guinea pig to see if gyp could plausibly work for more than Google's ports. The Wx port probably has the lowest resources of any complete port in the tree, so they might not be the best choice of experimental subject, particularly if for them the process required writing a new gyp back end and if they are not yet entirely comfortable going the gyp route. I would need to discuss it with my student, but what about the brand new Haiku port being the gyp guinea pig? For those who don't know, I am mentoring a student in the Google Summer of Code for the Haiku operating system (http://www.haiku-os.org) and we are working on a native Haiku web browser with WebKit as the rendering engine. I don't know if our port is any better of a choice than the Wx port, since the resources are also small (just two of us for now) and we aren't even in the WebKit tree yet, but I think we still might be a good choice because: 1) We obviously don't yet have a production browser using our port so breakage isn't an issue. Plus only my student (Maxime Simon) and I are working on it. 2) I have decent experience with build systems and think I could handle working with gyp and writing a new back end. 3) Haiku generally uses Jam for building and we would like our port to do the same. Rather than adding Yet Another Build System to WebKit, we could use gyp and write a Jam backend for it. This can therefore serve as a test of gyp for another platform as well as for another backend. I would rather not have to maintain a Jamfile for WebKit if I can avoid it, and I certainly don't want to burden the other WebKit developers with having to maintain it for what is now (and may forever be) a tiny port. Though we certainly hope Haiku's popularity increases in the future (it hasn't even had a first release anyhow, so there is plenty of room to grow.) Anyhow, I'd be interested in hearing what other people think. -- Regards, 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] NeverNullT
On Tue, Jul 28, 2009 at 9:53 PM, Roland Steiner rolandstei...@google.comwrote:
I definitely like the general idea, but I don't think a NeverNull template
is worth it in the general case, for the following reasons:
First, I don't hink you can catch even a meaningful subset of all cases of
NULL assignment at compile time. OTOH, writing a template class that wraps a
non-null pointer has its use mainly in order to annotate header files, and
to auto-insert the ASSERT. In cpp files it's just a cosmetic difference to
ASSERTs, and enforcing the use throughout would probably change far too much
code, and run into other cumbersome details in addition to the ones I
mention below.
OTOH in order to be consequent, one would also need to use NeverNullX in
return values, e.g.,
NeverNullfoo bar() const;
Implementing such a function would have to be conscious of the fact that a
NeverNullX must always be initialized. i.e., you cannot write
NeverNullfoo Baz::bar() const
{
NeverNullfoo returnValue;
... compute returnValue ...
return returnValue;
}
Couldn't you just create a const foo constructor and a (foo) operator
in your NeverNull template class to get around this? The constructor would
have an ASSERT to check that the value is not NULL, so (in theory) it'd just
be a dumb wrapper in release mode.
It's _possible_ modern day compilers would be smart enough to handle this.
That said, I think the only way to talk inteligently about the performance
implications is for someone to try it out on some popular code paths.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Towards a commit-queue
On Sat, Aug 1, 2009 at 11:45 AM, Ojan Vafai o...@chromium.org wrote: On Sat, Aug 1, 2009 at 2:08 PM, Adam Barth aba...@webkit.org wrote: On Sat, Aug 1, 2009 at 11:04 AM, David Kilzerddkil...@webkit.org wrote: Bugzilla has the ability to create additional 4-state flags at both the attachment level and at the bug level. (Note that bugs.webkit.org does not have bug-level flags enabled.) For example, we could create a commit attachment flag which would have four states (just like the review flag): none, commit?, commit+, commit-. I'm not sure if this helps or hurts, though it would have made abarth's desired workflow much nicer. Yeah, that sounds great. Should we try that out for a while and see if it's useful? This seems fine to me, except it adds yet another layer of complexity to the review process. I think getting patches landed more quickly is probably worth it though. This is essentially a slightly more complicated (but easier to implement?) version of Maciej's proposal from a few weeks ago to get rid of r* and have the following four review states: REQUESTED DENIED APPROVED WITH MODIFICATIONS APPROVED It seems to me that the only difference is APPROVED becomes READY TO LAND (or LANDABLE or something like that). Btw, I see one downside to a commit queue: When you manually commit something, you're supposed to watch the build bots for breakage. If the submit queue is running all the tests on all the platforms then it doesn't really matter, but if not there'll need to be automated rollbacks when things break on the waterfall build bots. This could easily become complicated if the commit queue can submit multiple patches before the waterfall bots show green for the previous patch. I guess the point that I'm trying to make is that tests should either be run on every buildbot configuration, there needs to be some pretty robust rollback code, or the queue needs to let everything cycle green before committing the next patch. The last suggestion seems like a good start. Note also that, if the system rolls back a patch and the bots don't go back to their previous state, the submit bot needs to stop so someone can take a look manually (so things don't get further hosed). One benefit over the above is that, I don't think we need to restrict commit+ to people with svn commit bit, as long as a patch is r+'ed or r+'ed with modifications. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Reporting exceptions from worker context to users
I think logging to all connected pages' console is fine for now, but I think Michael's suggestion (or something similar) should be implemented in the not too distant future. Definitely before shared workers are allowed to communicate with each other. J On Sat, Aug 1, 2009 at 12:45 PM, Michael Nordman micha...@google.comwrote: it sounds like we have one vote for just log them to the console for every connected document sgtm On Sat, Aug 1, 2009 at 12:39 PM, Drew Wilsonatwil...@google.com wrote: Yes, SharedWorkers will eventually be able to communicate with one another, as will DedicatedWorkers. So at some point we'll have a big connected graph of workers that potentially might be interesting for people to traverse and inspect their global contexts (I'm not sure - I don't think we know yet what debugging tools will be useful for developers). Further agreed, the HTML5 spec states that exceptions from shared workers are *not* propagated to parent pages for application execution - this would be solely for logging purposes. In the meantime while we work towards our glorious future, I'd still like to log exceptions somewhere :) It sounds like we have one vote for just log them to the console for every connected document. -atw On Sat, Aug 1, 2009 at 10:35 AM, Michael Nordman micha...@google.com wrote: Shared workers can also communicate directly with one another, is that right? And its possible to have a shared worker whose only client is another shared worker, is that right? Feels like we should be working towards inspecting shared workers directly. Where a page inspector would show which shared workers it was connected to, and you could open a separate inspector to see what is going on within each shared worker (including which shared workers it was connected to). Broadcasting exceptions within a worker to its clients for inspection purposes may be useful even with separate inspectors per shared worker. The client's 'shared worker' tab (or console) could log unhandled exceptions occurring in each, as you described, encouraging the developer to look into it... open the shared worker inspector and poke around. About broadcasting unhandled shared worker exceptions in general... It makes sense to have unhandled exceptions in a dedicated process propagated to the parent page's context (which may presumably handle the exception in some way). But I'm not sure that model applies to unhandled exceptions in shared workers. The possibility of multiple connected pages, which should handle it? Seems good for logging/debugging purposes to have them show up in the client's inspector, but doesn't sound like a good fit for application execution purposes. On Sat, Aug 1, 2009 at 9:31 AM, Drew Wilsonatwil...@google.com wrote: Hi all, Currently, unhandled exceptions are sent from worker context over to the parent page where they are logged to the console. This works fine for dedicated workers, but not for shared workers which can have multiple active windows. The immediate solution that springs to mind is to broadcast the exception to every window associated with a shared worker, and have each window log the unhandled exception to its console. Is there another option that might be better (is there the concept of an inspector/console that is not associated with a specific window, for example)? -atw ___ 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] automatic webkit bugzilla bug-posting / management tool
Have you looked at WebKitTools/Scripts/bugzilla-tool? There's a lot of
overlap between what it does and what you do, but there are definitely (very
cool) features in yours that it doesn't have.
Maybe you or someone else could try pulling some of this logic into
bugzilla-tool? Both are written in Python, so it might not be that hard!
J
On Sat, Aug 8, 2009 at 11:01 AM, Luke Kenneth Casson Leighton
luke.leigh...@googlemail.com wrote:
as part of managing 29 patches to webkit i decided to develop a system
which parses the ChangeLog entries and re-creates the patches. but -
not only that, there's a system for automatic uploading of the patch
attachment, as well:
http://lkcl.net/webkit/patman
it could probably be adapted equally well to work on any bugzilla
system, but the Webkit ChangeLog format makes it particularly
convenient to use.
one of the important things that the patman tool does is re-create the
ChangeLog entry at the _top_ of the relevant ChangeLog file, and also
it updates the date.
then, it goes through looking for the files listed in the ChangeLog,
and splits them out of the svn diff (yes, there's a diff/patch parser
included in the tool)
also, it looks for the first https://bugs.webkit.org entry, parses the
number and then spits out the re-formatted patches in to a file
patches/patch.bugnumber.txt
then, if you want to submit the patch as an attachment, run
patman/poemposter.py (yes, that's where the code came from - poem
posting :) with the following arguments:
bugnumber 'bugdescription' [optional review flag - use ? to request review]
the [daftly-named] poemposter.py will search for the file
patches/patch.{bugnumber}.txt and will upload it automatically to
bugs.webkit.org, to the requested bugreport.
you will need to create a file login.txt with:
user: email address
pass: bugzilla password
as this is a bit of a hack-job, you will need to do svn diff f -
patman/patchsplit.py doesn't accept any arguments yet, it just assumes
that there is a file f in the current working directory.
also, the tool must be run from the top-level webkit svn.
but, it should prove to be incredibly useful to those people
submitting bugreports for review, and save a great deal of time.
also, the patch-parsing system on its own might prove to be useful for
the commit queue processing, as it is capable of splitting out the
contents of patches e.g. individual ChangeLog entries.
you can see the process by which the ChangeLog entry is re-created as
a diff (see use of FakeChangeSet) that is always at the top of the
file.
l.
___
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 and Khronos Group
On Sat, Aug 8, 2009 at 2:02 PM, Maciej Stachowiak m...@apple.com wrote: On Aug 8, 2009, at 11:39 AM, Harry Underwood wrote: Thanks for the link. Didn't even know that WebGL is being considered by WebKit. What Oliver showed you is patches to pretty much fully implement it, done by an Apple employee. So we're doing more than considering it. I expect there will be more to announce when the patches land. But another question, if you don't mind. Is O3D considered as a technical competitor or conflict with Apple's CSS and SVG extensions, or should it be considered as such? We do have some extensions to do 3D transforms with CSS, creating 2.5D visuals with flat CSS boxes manipulated in 3D, and fully integrated with the page content. For example, you can use it to apply 3D effects to a navigation menu or a video. O3D is much more about creating full 3D models and scenes, without tight integration with the Web content. In that respect, O3D is more of a competitor for WebGL than 3D transforms/transitions. I'm not personally involved in the WebGL or O3D efforts, but I can speak to some of this. I agree that O3D and WebGL are more similar to each other than the CSS 3D transforms. Both are fairly low level, though they take fairly different approaches to rendering. O3D is a retained mode API (somewhat like SVG) whereas WebGL is an immediate mode API (much like Canvas). In other words, for O3D, you use JavaScript to build up a scene and transform it between frames. In WebGL you use JavaScript to explicitly render each frame. The latter gives you more control but is more limited by the speed of JavaScript and the WebGL bindings. I guess the point I'm trying to make here is that all three technologies are actually complementary to each other. Incidentally, it's my understanding that Google showed off a prototype version of Chrome running both O3D and WebGL at some conference last week. It's pretty cool how fast things are moving with respect to 3D on the web. :-) Jeremy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fwd: WebKit and Khronos Group
On Sun, Aug 9, 2009 at 12:32 AM, Maciej Stachowiak m...@apple.com wrote: On Aug 8, 2009, at 11:58 PM, Harry Underwood wrote: Thanks very much for the explanations, everyone. Sorry about the long chain of questions, but I wanted to form a FAQ-type basis for future questions regarding the difference between what Apple and WebKit are doing with SVG+CSS and what Google and Khronos Group are doing with O3D vs. WebGL, Even that way of framing it sounds potentially inaccurate. Some corrections: - Neither Apple nor WebKit are specifically trying to do something with SVG+CSS. We do support SVG, and we have some CSS extensions, but we're not especially pushing this combination. - We're hoping others adopt our 3D CSS transforms, just as our 2D CSS transforms and CSS transitions have gotten interest from Mozilla and others. - Apple, along with Google, Mozilla, Khronos Group and others, is actively supporting WebGL. - O3D is, at least for now, a Google-only technology. I'm not on the O3D team, but it's my understanding that they're trying to get O3D (or some sort of retained mode 3D API) on a standards trackso hopefully it won't be Google-only for much longer. :-) Also note that O3D is open source software ( http://src.chromium.org/viewvc/chrome/trunk/src/o3d/) and is available as a plugin for many browsers (not sure which ones specifically, though). So maybe plugin-only is a better way to describe it at the moment? - None of these technologies serve quite the same purpose. at least because a number (a minority, most likely) of people are highly interested in the post-VRML 3D Web nowadays. There's definitely a lot of people interested in 3D. It would be good to collect the information about this. I think Maciej summed things up very precisely (besides my one nit of a comment). J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Documenting common null pointer errors
On Tue, Aug 11, 2009 at 3:59 PM, Eric Seidel e...@webkit.org wrote: Didn't we just have a thread about this a couple weeks ago, and decided that it's better if the Compiler checked/documented this sort of thing? Oliver had worked on some classes to enforce null checking iirc... This is related but different. It's more about documenting the dependencies and how/when things become null rather than whether they _can_ become null. Speaking of which, is anyone working on that other idea? J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] svn-* scripts
On Fri, Aug 21, 2009 at 5:57 PM, Joseph Pecoraro joepec...@gmail.comwrote: On Aug 21, 2009, at 8: 32PM, Darin Adler wrote: I’m a little irritated that we’re changing our Subversion scripts, svn-create-patch, svn-apply, and svn-unapply into WebKit-specific scripts. Previously, they were scripts that were independent of the particular project that enhanced Subversion in a non-project-specific way. I used the WebKit version on many projects other than the WebKit project. I think the names should change if we’re changing them to do WebKit-specific things. I don't think the change I did before was WebKit specific. And the changes (not committed) to svn-[un]apply only reflect the changes to svn-create-patch, but are again not WebKit specific. These changes ensure that patches are created and applied from the root of any SVN Repository (which in fact is what git does by default and makes the most sense by removing any possible ambiguity or forcing someone to know which directory they should apply a patch). There has been some loss of functionality [1], but that can be fixed. [1] Create a patch without svn-create-patch which contains paths not from the repository's root and then attempting to use svn-apply or svn-unapply to deal with the patch. These are the only changes I know of. If there are any others its possible they may be WebKit specific. Even if they were WebKit specific, I guess i don't see what the problem would be. After all, the tools are checked into WebKitTools in the webkit repository. Making them more useful for WebKit development at the expense of other development seems like an OK trade-off to me. Note that you could always grab a version of the files from back when they behaved the way you wanted and stick them in ~/bin (or some other dir on your path). ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Whitespace changes
On Thu, Aug 27, 2009 at 1:37 PM, Mark Rowe mr...@apple.com wrote: On 2009-08-27, at 12:57, Dirk Pranke wrote: On Thu, Aug 27, 2009 at 11:55 AM, Peter Kastingpkast...@google.com wrote: On Wed, Aug 26, 2009 at 10:43 PM, David Levin le...@chromium.org wrote: fwiw, I know that the check-webkit-style checks for trailing whitespace (and I approved that change - sorry), but I think it should probably be removed. Since opinions were requested, I'm in favor of both the check-webkit-style change here and Adam's patch, as well as other cleanup patches. Maintaining a cultural attitude that is widely positive towards cleanup makes people feel less reticent about cleaning up, and taking ownership of, code; frowning on certain types of cleanup makes people less likely to do _any_ cleanup. As far as blame annotations, I don't mind paging past a cleanup change when trying to do archaeology on code; I have to go past enough other changes already that one more doesn't make much of a difference overall. +1 I see little point in having coding standards if you don't encourage people to use them. There is enough churn in the tree that there are already a large number of changes to skip over, so skipping over reformatting (even whitespace-only) seems like a small burden to me. There's a difference between enforcing our coding style on new code, and retroactively applying our new style to the hundreds of thousands of lines of code that already exist. Your comment conflates these two issues. No-one is going to disagree that we should enforce the coding style on new code. That would be stupid. However it is clear that applying our current coding style to existing code is a much less clear-cut issue. We wouldn't be having this discussion if it were as obvious as your comment suggests. There's also a huge difference between enforcing WebKit coding style and enforcing some other coding style. Trailing whitespace is not mentioned in the WebKit coding style guidelines. Can we add it then? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] I *HATE* CHANGELOGS!!!
On Fri, Aug 28, 2009 at 12:26 PM, Brady Eidson beid...@apple.com wrote: On Aug 28, 2009, at 12:18 PM, George Staikos wrote: On 26-Aug-09, at 2:44 PM, Maciej Stachowiak wrote: On Aug 26, 2009, at 5:38 PM, Geoffrey Garen wrote: Detailed descriptions, bug links, test instructions, and a link back to the entire original review history are all part of Chromium commits, yet we don't use ChangeLogs. I think discipline about what to include + tooling to support it are orthogonal to a project's use of a ChangeLog as the mechanism for conveying this information. [This question not necessarily just for Peter:] If we removed the discipline of reviewing ChangeLogs, and the tools that autogenerate a ChangeLog template and check for a ChangeLog entry without an OOPs I didn't get this reviewed message, what would we replace them with? I can imagine a discipline where we ensure that pending commit entries sit in a designated file in your tree, are made by a tool much like prepare-ChangeLog, are included in patches by svn-create-patch, are applied by svn-apply-patch, and are used by commit-log-editor. That would ensure the entries go through the patch life cycle just as much as currently. Another possibility is to have a review site (bugzilla?) be the canonical place for log entries until they get committed. At commit time, a tool would pull from this location. I want to add a +1 for the hate changelogs group. I have been advocating this for about 4 years now. It's much more painful when on a remote, slow link. Is it really a problem to generate the ChangeLog files from the svn commit messages on a daily or weekly basis? There are scripts for this. This is an interesting idea. Mark Rowe already pointed out - doing an automated step for each checkin that causes another checkin would be ridiculous. But how about a nightly script that checks in a ChangeLog accounting for the day's commits? Seems reasonable to me. +1 +1 Agreed. If it's done daily, Trac would be a good way to look at what's happened very recently. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Runtime setting for incomplete features
On Fri, Sep 18, 2009 at 12:59 PM, Alexey Proskuryakov a...@webkit.org wrote: 18.09.2009, в 12:24, Jeremy Orlow написал(а): I'm not sure if we've hit any compatibility issues with this yet, but it seems quite plausible that someone would compare window.localStorage (or sessionStorage or database) to undefined and, since it's null (vs. undefined), their script would assume it's available. Note that they can also do 'localStorage in window', which we can't easily prevent from returning true. That's true. And unfortunate. What would be involved in making it not return true? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Runtime setting for incomplete features
On Mon, Sep 21, 2009 at 1:22 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 21, 2009, at 12:31 PM, Jeremy Orlow wrote: On Mon, Sep 21, 2009 at 12:17 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 18, 2009, at 1:30 PM, Jeremy Orlow wrote: On Fri, Sep 18, 2009 at 12:59 PM, Alexey Proskuryakov a...@webkit.orgwrote: 18.09.2009, в 12:24, Jeremy Orlow написал(а): I'm not sure if we've hit any compatibility issues with this yet, but it seems quite plausible that someone would compare window.localStorage (or sessionStorage or database) to undefined and, since it's null (vs. undefined), their script would assume it's available. Note that they can also do 'localStorage in window', which we can't easily prevent from returning true. That's true. And unfortunate. What would be involved in making it not return true? It would be pretty complicated to do that based on a runtime setting. You would need a custom getter for any object that has properties which may appear or disappear based on settings. Some of these already have a custom getter. Maybe it makes sense to go ahead and do it for them? This is probably too complicated to be worth it. Or at least, if we added that level of code complexity I would begin to doubt the merits of supporting runtime enabling of Web platform features. I think it depends on why it's enabled at run time. If it's a feature that some users might want to completely turn off, then I think there's some merit to going the extra mile to disable it in run time. But if it's something that's disabled because it's experimental, then I'd lean towards your point of view. Fair enough. But I would be against user-level preferences that add or remove entire APIs. Rather, the preference should affect the behavior of the API (possibly making it do nothing). So far the only actual user-level preference I'm aware of that effectively disables APIs is private browsing. And I think the way it works (in both Safari and Chrome, even though it is different) is better than it would be to make storage-related APIs disappear completely. Agreed. I would think something like disable Java (not the best example, but I think it makes the point) should have obvious side effects though. That said, I can't think of any JavaScript APIs where it does make sense today. And, if not, then we should probably differ such a discussion until there is. Which is a shame, because if (localStorage in window) is a generally a better way to feature test than if (window.localStorage). The latter idiom is problematic for attributes where a possible valid value is something that evaluates to false, or where computing the value can be expensive. For example, if (document.body.outerHTML) would be an awful way to test whether outerHTML is available. Agreed. In practice, I can't think of anything we'd disable in run time like that, but it's obviously more difficult for the web developer to know this. Even though this style of feature test is better, it's tragically much less common than if (window.fooBar), so it's likely not a problem in practice. Even if we can't make the property not show up, would you agree that returning undefined is better than returning null? Slightly better. The only real difference it would make is if someone tests using a === comparison to undefined (as opposed to == or just a plain boolean test). Given that this really only applies to experimental features, I don't think we should spend too much effort on this. But Drew, I do think it'd be valuable if you played around with it. And if any of this isn't too hard/messy to do, I think it would be somewhat valuable. I'm also going to send mail to chromium-dev proposing that we never ship anything but a dev channel browser with such experimental features compiled in for the reasons we've discussed here. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Issues with Workers
A first pass could just handle anything that can serialize to JSON. I believe this is more or less what FireFox supports at the moment and gets you half the way there. On Mon, Sep 28, 2009 at 1:37 PM, Drew Wilson atwil...@google.com wrote: There is this: https://bugs.webkit.org/show_bug.cgi?id=22878 The issue extends beyond workers - it's anything that supports the postMessage() API (window objects, MessagePorts). As was pointed out previously, there have been some design discussions in this area, but I haven't seen any patches yet (and since serialization is closely tied to the JS VM on each platform, we will undoubtedly need to have two implementations - one for JSC and one for V8). -atw On Mon, Sep 28, 2009 at 1:15 PM, Mark Rowe mr...@apple.com wrote: On 2009-09-28, at 10:23, Chris Campbell wrote: Hi Tali, Regarding event.data, there is a chromium issue filed for this here: http://crbug.com/21299 Given that this would seem to be an issue at the WebKit level, is there a bug in WebKit bug about this issue? - Mark ___ 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] Runtime setting for incomplete features
On Mon, Oct 5, 2009 at 6:40 PM, Sam Weinig sam.wei...@gmail.com wrote: On Mon, Oct 5, 2009 at 6:33 PM, Drew Wilson atwil...@google.com wrote: On Mon, Oct 5, 2009 at 6:20 PM, Sam Weinig sam.wei...@gmail.com wrote: On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson atwil...@google.com wrote: I'm surprised to see these objections coming up now, weeks after the original discussion, and only after my patch has landed in the tree. Sorry, I seemed to have missed that thread. I did however file a bug as soon as the first runtime switch went in. That said, I agree that in an ideal world, we'd hide window.audio, shared workers, notifications, local storage, databases, session storage and any other runtime/platform-disabled API from enumerations - I just agree with Maciej that this isn't a hugely important issue, since these features are only runtime-disabled while under development and so not widely available anyway. I obviously disagree with Maciej on this. I think it is bad to break developers expectations for feature detection. OK, it's good to get consensus, even if it comes after I already thought we had achieved it :) From a purist's perspective, I see where you're coming from. Pragmatically, though, these runtime flags are only available on the Chrome dev channel (and go away before the features are ever shipped to the beta/stable channels) so the compatibility issues are somewhat moot. We've discussed removing these feature flags (and the ability to disable the features at runtime) once the features become stable - I don't know if that's a good idea or not, but that might impact this discussion as well. That is not true, they are also available in nightly builds at http://nightly.webkit.org/. If there are any features in the Safari WebKit nightlies that are enabled at compile time but disabled at run time, this is likely unintentional and is what should be fixed. More on this below Regardless, I don't think we should rush out to roll all of those features out of the tree, and I certainly don't think we should be singling out SharedWorkers or WebSockets I don't mean to single out SharedWorkers or WebSockets, but I don't see any others using the same technique (barring window.Audio, which I don't think is the same thing, but should non-the less be fixed). But, as we have many developers using the nightlies, I think this should be handled with some speed. Take a look at DOMWindow.cpp - there's quite a bit of code that does something like look at settings to see if feature is enabled, return null if not (DOMWindow::openDatabase(), for an example). This is indeed unfortunate, but also is a step removed, since it does not really effect feature detection, it is also not a shipping configuration. They were originally added in this patch: http://trac.webkit.org/changeset/38234 Note that that patch exposes them through the windows and mac WebKit APIs, so I'm not sure you can really call it not a shipping configuration unless you're only talking about Safari. So here's the problem: These run time flags have all been modeled on the localStorage and database runtime flags. The problem with these flags is that you have to opt-in at compile time _and_ at run time. This probably makes sense for features that can have lasting side effects like localStorage and Database, but for features like WebSockets, Notifications, and SharedWorkers, its probably the wrong behavior. So maybe we should change the defaults in Settings to true for all of these? After all, if a feature is compiled out, then the setting will be ignored. And if it's compiled in, the port probably wanted it enabled anyway. It might actually be better to simply not compile in the Setting when the compile time flags are disabled, but that'd involve more #ifdef's. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Runtime setting for incomplete features
On Mon, Oct 5, 2009 at 9:45 PM, Maciej Stachowiak m...@apple.com wrote: On Oct 5, 2009, at 9:17 PM, Darin Fisher wrote: On Mon, Oct 5, 2009 at 6:43 PM, Maciej Stachowiak m...@apple.com wrote: On Oct 5, 2009, at 6:20 PM, Sam Weinig wrote: On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson atwil...@google.com wrote: I'm surprised to see these objections coming up now, weeks after the original discussion, and only after my patch has landed in the tree. Sorry, I seemed to have missed that thread. I did however file a bug as soon as the first runtime switch went in. That said, I agree that in an ideal world, we'd hide window.audio, shared workers, notifications, local storage, databases, session storage and any other runtime/platform-disabled API from enumerations - I just agree with Maciej that this isn't a hugely important issue, since these features are only runtime-disabled while under development and so not widely available anyway. I obviously disagree with Maciej on this. I think it is bad to break developers expectations for feature detection. My comments were specifically based on the Chrome team's plans to only have the runtime switch in dev channel builds, and always fully compile features out in release product. That's not how we do things. Sorry for the confusion. What ships in dev channel goes to beta provided it passes the quality metrics. What ships in beta goes to stable again provided it passes the quality metrics. We do not change the build configuration when promoting a build. Jeremy Orlow said said (in an earlier email): I'm also going to send mail to chromium-dev proposing that we never ship anything but a dev channel browser with such experimental features compiled in for the reasons we've discussed here. I did, and Darin rejected it. :-) I guess we should have brought the discussion back here after we talked about the Chromium half of that. Sorry. Others seemed to agree with that line of thinking. If his suggestion was rejected, then yes, we should go back to the drawing board. Shipping partly-detectable but disabled features in production builds would be bad. Therefore, it is essential that feature detection is done correctly even in dev channel builds. My apologies if you have received mixed messages on this. I'm concerned that the cost in code complexity for enabling runtime switching with perfect detectability properties may be high. The drivers for that cost seem (at first glance) like inessential aspects of the Chromium development process. Is there any fundamental reason that production builds have to ship with runtime-switchable experimental features? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Runtime setting for incomplete features
On Mon, Oct 5, 2009 at 9:54 PM, Mark Rowe mr...@apple.com wrote: On 2009-10-05, at 21:48, Darin Fisher wrote: It is a matter of our process that we do not change the configuration when promoting builds. The bits that passed the test get promoted. I'm happy to absorb this cost in the V8 bindings. I don't think it is important to solve this problem for the JSC bindings since there is not a consumer that yet needs the same. The present state of Web Sockets is that they're compiled in on Mac OS X but disabled via the runtime setting. This leads to them being detectable in the manner Sam mentioned. Either the compile-time setting needs to be fixed for Mac OS X or the runtime code fixed so that the feature is not detectable when disabled. I assume that we want regression testing of the feature so disabling it at compile time does not seem like the best idea. I guess it comes down to whether or not it's in good enough shape to be useful to web sites at this time. I don't believe that anyone is shipping a working implementation of WebSockets yet (or is Firefox's working now?), in which case it shouldn't matter to have it on by default. Are there any other examples of things being on at compile time but off at run time by default? If so, let's file some bugs and fix things up. Shouldn't be too hard. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Documenting common null pointer errors
k On Tue, Oct 6, 2009 at 3:00 PM, Adam Barth aba...@webkit.org wrote: On Tue, Oct 6, 2009 at 2:49 PM, Jeremy Orlow jor...@chromium.org wrote: Did this ever get linked from the home page? Nope. The web site is in SVN. Go ahead and file a bug and attach a patch. :) Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Landing your own patches
This only works when you set the commit-queue+ bit. Currently, the convention is that people without commit access set commit-queue? to signal that they'd like a reviewer to commit-queue+ it when they r+ it. Sometimes reviewers will go so far as to commit-queue+ it unless they see a commit-queue-. Since there's no way for someone to know when their patch is going to be reviewed, it seems like this may be what's broken about the system. Maybe reviewers should never commit-queue+ stuff. And non-committers should just ask on IRC for someone to commit-queue+ their patch when it's ready to land. J On Wed, Oct 14, 2009 at 2:10 PM, Julie Parent jparent+web...@gmail.comjparent%2bweb...@gmail.com wrote: It seems like if you are a committer, you should still be able to use the commit queue, you just need to do it responsibly. If the problem is with people setting the bit and walking away, why not include a warning to the effect of: Setting commit-queue+ is equivalent to svn commit so it is understood that you should follow the same policies when setting the bit as you do when committing manually? For example, my workflow is as follows: 1. Check the status of the commit queue to make sure it isn't busy and is ready to accept my patch 2. Make sure I'm logged into #webkit 3. Set commit-queue+ 4. Wait ... watch for IRC notifier for my commit (simple notifier set up on my username) 1. If my commit doesn't go through and I need to leave my desk, set commit-queue- so it doesn't commit while I'm away. 5. Watch the tree and make sure there was no issues If anything, I'm being a better citizen because I'm running the tests on both Windows (locally) and Mac (commit-queue) before submitting. (Agreed that this is the wrong tool, try severs would be better, but in the absence of try servers, I don't see how I'm causing harm by using commit-queue). Julie On Wed, Oct 14, 2009 at 12:38 AM, Adam Barth aba...@webkit.org wrote: Has this actually been a problem? I know the commit-queue broke something today when landing a patch for Evan Martin, but he was on IRC and I made sure he was on the hook to watch the bots before I had to leave. If I've landed things via commit-queue and not cleaned up after them, I certainly apologize. Eric has talked about having the commit-queue watch the bots and send out email to the appropriate people when the commit-queue breaks something. What I see as more of a problem is the failing tests on Tiger and SnowLeopard the past few days. Having red columns on the tree makes it harder to see when a new regression is introduced. Looking at the tree, the issue seems to have been resolved. If that was caused by the commit-queue, then I agree we should improve the commit-queue process. If it was caused by someone committing their own patch, then I think we should improve the self-commit process. Adam On Tue, Oct 13, 2009 at 11:22 PM, Sam Weinig sam.wei...@gmail.com wrote: Hi WebKit Developers, As nice as it may be to have a bot landing your patches, I think developers who have a commit bit should try and make the effort to land their own patches. Mainly I think this is a good idea since the creator of the patch has a much better chance of fixing the issue or quickly rolling it out if they have to consciously commit and watch the bots. It also, and perhaps more importantly, places a lesser burden on the community who ends up doing this job for them. I understand the concern of those working on Windows who don't necessarily have access to a Mac and I applaud your fear of breaking the build, but I think in the end you are using the wrong tool (admittedly due to a lack of trybots, but the commit bot will not run Qt or Gtk) and you are using it too much (most patches probably won't break a build, unless you are named Dave Hyatt). Thanks, -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
FYI, this was filed some time ago: http://code.google.com/p/chromium/issues/detail?id=3527 https://bugs.webkit.org/show_bug.cgi?id=21960 On Mon, Oct 19, 2009 at 1:03 PM, Ben Goodger b...@google.com wrote: I agree. I would like to retain this mode of selection in Windows Chrome at least. I think it's only ragged in most apps because people don't take the time to make it look nice. -Ben On Mon, Oct 19, 2009 at 12:57 PM, David Hyatt hy...@apple.com wrote: On Oct 16, 2009, at 7:07 PM, Evan Martin wrote: When you select multiple lines of text in WebKit, the highlight paints over whitespace on the right margin. This is correct behavior for Mac, but not for Windows or Linux. I would suggest making it be controlled by a Setting rather than #ifdefs. I thought one existed already, but if it doesn't, we can add one. Another possibility might be using the theme to query for this info, although I know we would like to preserve the gap painting on Safari for Windows. Therefore a Setting is probably best. Keep in mind that eliminating the gaps will give you a pretty ugly irregular selection in a lot of places. Do what you want in Chrome, but make sure it's a setting and that you don't change Safari for Windows in the process. Thanks, dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why are PassRefPtrs used as function parameters?
My thinking is that we should be consistent. And given that passing a raw
pointer is equal to or faster than passing a PassRefPtr it seems to me that
we should just do that whenever ownership isn't being transfered. Note that
this is what's done in the majority of cases I've seen and it's what the
RefPtr doc recommends, IIRC.
I don't see why the distinction between a callee simply using an object or
adopting it for future use is terribly interesting to the caller.
J
On Thu, Oct 29, 2009 at 3:55 PM, Drew Wilson atwil...@google.com wrote:
Aside from the ref-counter munging, it still seems like there's value in
using PassRefPtr as a signifier that a given API takes ownership of a
pointer.
So I'm not certain (in the case of HTMLNameCollection) that it'd be a
better solution to change it not to take an ordinary pointer - yes, it would
eliminate some ref churn, but at the cost of losing that connotation.
A better solution (since the constructor is private) would be to make the
constructor explicitly take a CollectionCache* parameter, thereby allowing
us to directly pass the document straight through to the base class.
-atw
On Thu, Oct 29, 2009 at 3:31 PM, Maciej Stachowiak m...@apple.com wrote:
On Oct 29, 2009, at 12:56 PM, Darin Adler wrote:
On Oct 27, 2009, at 10:55 AM, Jens Alfke wrote:
Looking at how refcounting is implemented in WebCore, I was surprised to
find that there are a lot of functions/methods that take PassRefPtrs as
parameters instead of regular pointers to those objects. I can't see any
benefit to this, and it adds the overhead of a ref() and deref() at every
call-site.
Have you read the RefPtr document? It is at
http://webkit.org/coding/RefPtr.html.
Only functions that take ownership of the passed-in objects should take
PassRefPtr. This makes it so we can optimally handle the case where that
object was just created and lets us hand off the reference instead of having
to do a round of reference count thrash. If the function is going to be
storing the value in a RefPtr, then the PassRefPtr does not introduce any
reference count thrash even if the passed in object was not just created.
It’s wrong for the HTMLNameCollection constructor to take a PassRefPtr
for its document argument because it doesn’t take ownership of the document.
So that one is definitely a mistake.
However, its base class HTMLCollection can take ownership. The
HTMLNameCollection constructor misses out on the optimization though:
HTMLNameCollection::HTMLNameCollection(PassRefPtrDocument document,
CollectionType type, const String name)
: HTMLCollection(document.get(), type,
document-nameCollectionInfo(type, name))
, m_name(name)
{
}
Note that it passes document.get(), but also uses document after that so
it couldn't just pass document. Thus, it probably shouldn't take a
PassRefPtr (unless there is a clever way to fix it that I'm not seeing).
- Maciej
It is true that PassRefPtr arguments can be tricky as you mentioned and
the RefPtr document also mentions.
-- 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
___
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] MutationEvent
Did try svn blaming it and looking at the corresponding changelog entry?
On Mon, Nov 2, 2009 at 2:56 PM, Yong Li yong.li.web...@gmail.com wrote:
Hi, All,
Why there are #if 0 here? First, I'm told #if 0 is not webkit style.
Second, the disabled code seems useful.
void Element::dispatchAttrRemovalEvent(Attribute*)
{
ASSERT(!eventDispatchForbidden());
#if 0
if (!document()-hasListenerType(Document::DOMATTRMODIFIED_LISTENER))
return;
ExceptionCode ec = 0;
dispatchEvent(new MutationEvent(DOMAttrModifiedEvent, true, false,
attr, attr-value(),
attr-value(), document()-attrName(attr-id()),
MutationEvent::REMOVAL), ec);
#endif
}
void Element::dispatchAttrAdditionEvent(Attribute*)
{
ASSERT(!eventDispatchForbidden());
#if 0
if (!document()-hasListenerType(Document::DOMATTRMODIFIED_LISTENER))
return;
ExceptionCode ec = 0;
dispatchEvent(new MutationEvent(DOMAttrModifiedEvent, true, false,
attr, attr-value(),
attr-value(), document()-attrName(attr-id()),
MutationEvent::ADDITION), ec);
#endif
}
Best regards,
-Yong
___
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] A bot-filled future?
It's so easy to have code that builds on one platform but not another. Even if the try servers were only builders to begin with, I think they'd provide a lot of value to the project. On Thu, Nov 12, 2009 at 11:43 AM, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: I think that sounds like a really good idea, and I can see my self using that when touching cross platform code. Kenneth On Thu, Nov 12, 2009 at 4:37 PM, Adam Barth aba...@webkit.org wrote: As the project grows, we need to scale our processes to match. In large part, that means automating as much work as possible. Commit-queue has done a good job of solving the land patches from non-committers efficiently problem, effectively removing that as a pain point. I'd like to ask you to open your hearts and your minds to the idea of automating more of our processes. Currently, I see the biggest pain-point in our process as the always-burgeoning pending-review list. It's difficult to automate the process of accepting good patches because that requires attention from experts. Instead, I think we should make it easier to reject bad patches. As a first step, I've started extending bugzilla-tool to be a try server in https://bugs.webkit.org/show_bug.cgi?id=31422. Here's how this might work: 1) Contributor posts patch for review. 2) Committer marks patch with the try? flag. 3) The try-queue downloads, applies, builds, and tests the patch. 4) If all systems are go, the try-queue marks the patch as try+. Otherwise, it marks the patch as try- with an explanation of what went wrong. The try-queue will be purely optional and advisory. Hopefully a try- notation will encourage the contributor to post a new version of the patch that passes the try-queue. Further down the road, one can also imagine another bot that automates step (2) by scanning the pending-review list for untried patches and marking them as try? when the try-queue has unused bandwidth. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.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] A bot-filled future?
That sounds good to me. As for the security issues: It seems like we could build code from anyone but only run the tests from committers. On Thu, Nov 12, 2009 at 2:43 PM, Adam Barth aba...@webkit.org wrote: On Thu, Nov 12, 2009 at 1:04 PM, Mark Rowe mr...@apple.com wrote: 1) People are already confused about how to handle the recently-added commit-queue flag. Adding an extra flag is going to increase the confusion. I chatted with Eric about how to solve this problem. One option is to just try every change that has review? and add a comment to the bug about success / failure. That minimizes the UI surface and avoids adding yet-another-flag. 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] A bot-filled future?
Ok. The only run stuff uploaded by committers automatically? Maybe have a web page committers can visit to submit (i.e. vouch for) patches to be run through the bots? J On Thu, Nov 12, 2009 at 2:52 PM, Brian Weinstein bweinst...@apple.comwrote: What if someone changed build-webkit or the build procedure in one of the vcproj's? On Nov 12, 2009, at 2:50 PM, Jeremy Orlow wrote: That sounds good to me. As for the security issues: It seems like we could build code from anyone but only run the tests from committers. On Thu, Nov 12, 2009 at 2:43 PM, Adam Barth aba...@webkit.org wrote: On Thu, Nov 12, 2009 at 1:04 PM, Mark Rowe mr...@apple.com wrote: 1) People are already confused about how to handle the recently-added commit-queue flag. Adding an extra flag is going to increase the confusion. I chatted with Eric about how to solve this problem. One option is to just try every change that has review? and add a comment to the bug about success / failure. That minimizes the UI surface and avoids adding yet-another-flag. 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] A bot-filled future?
I think the main reason why we don't yet have a try server is that we block it on stuff like this...which is nice to have. It seems like we could get something basic up that worked for 90% of cases and then iterate on something more featureful. I think Adam has the right idea here. J On Thu, Nov 12, 2009 at 3:38 PM, Ojan Vafai o...@chromium.org wrote: This approach doesn't lend itself as well to trying patches before putting them up for review. Specifically, I want to be able to try patches without spamming everyone with bugzilla mail. This is solvable in this bugzilla-based approach, but it doesn't lend itself to this as naturally, e.g. presumably there's a way to tell bugzilla not to send mail for a given comment. Also, it would be great if the commit-queue, try-server, whatever, had a UI like the buildbot waterfall. There's a couple advantages: 1. Can see the stdio as the tests run and get better information about why it failed. 2. Can grab layout test results from the try servers. This would reduce the need/occurence of committing Mac expectations and then cleaning up other platforms post commit. Ojan On Thu, Nov 12, 2009 at 12:58 PM, Brian Weinstein bweinst...@apple.comwrote: Seconded (or Thirded). I'd been working on a try-server using Chromium's try-change.py, but this seems like a much cleaner way to handle it, and ties into the Bugzilla workflow much better than my solution, and would be much easier to limit who can set the try bit, based on what we decide the policy to be. On Nov 12, 2009, at 12:41 PM, Jeremy Orlow wrote: It's so easy to have code that builds on one platform but not another. Even if the try servers were only builders to begin with, I think they'd provide a lot of value to the project. On Thu, Nov 12, 2009 at 11:43 AM, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: I think that sounds like a really good idea, and I can see my self using that when touching cross platform code. Kenneth On Thu, Nov 12, 2009 at 4:37 PM, Adam Barth aba...@webkit.org wrote: As the project grows, we need to scale our processes to match. In large part, that means automating as much work as possible. Commit-queue has done a good job of solving the land patches from non-committers efficiently problem, effectively removing that as a pain point. I'd like to ask you to open your hearts and your minds to the idea of automating more of our processes. Currently, I see the biggest pain-point in our process as the always-burgeoning pending-review list. It's difficult to automate the process of accepting good patches because that requires attention from experts. Instead, I think we should make it easier to reject bad patches. As a first step, I've started extending bugzilla-tool to be a try server in https://bugs.webkit.org/show_bug.cgi?id=31422. Here's how this might work: 1) Contributor posts patch for review. 2) Committer marks patch with the try? flag. 3) The try-queue downloads, applies, builds, and tests the patch. 4) If all systems are go, the try-queue marks the patch as try+. Otherwise, it marks the patch as try- with an explanation of what went wrong. The try-queue will be purely optional and advisory. Hopefully a try- notation will encourage the contributor to post a new version of the patch that passes the try-queue. Further down the road, one can also imagine another bot that automates step (2) by scanning the pending-review list for untried patches and marking them as try? when the try-queue has unused bandwidth. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.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 ___ 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
*cc'ing others involved in WebSockets (server and client side) I'm not very familiar with the IETF's efforts, but my understanding is that they were creating a competing protocol. Are they in fact creating something that they want to submit as a replacement to WebSockets? If so, why is WebSockets moving to last call? I'm not necessarily against this change, just confused by it. * On Fri, Nov 13, 2009 at 10:03 AM, Alexey Proskuryakov a...@webkit.org wrote: While WebSocket API is fairly stable, the discussion of underlying protocol at IETF is far from being done. It could be disruptive to ship our WebSocket implementation in a way that would effectively freeze the protocol. One way to achieve future compatibility is by using a different scheme for WebSocket URLs - e.g. webkit-ws: and webkit-wss: instead of ws: and wss:, respectively. Depending on how protocol standardization goes, we could alias these later, or add a separate standards compliant implementation. I'm going to submit a patch to this effect, but would like to discuss the idea on the list first. - WBR, Alexey Proskuryakov ___ 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
Oops...I missed that. SGTM then. On Fri, Nov 13, 2009 at 11:14 AM, David Levin le...@chromium.org wrote: There is the browser side: http://www.w3.org/TR/2009/WD-websockets-20091029/ In that spec, it says This specification is being developed in conjunction with an Internet Draft for a wire protocol, the Web Socket Protocol, available from the IETF at the following location: - WebSocket Protocol Internet-Draft: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol On Fri, Nov 13, 2009 at 10:46 AM, Jeremy Orlow jor...@chromium.orgwrote: *cc'ing others involved in WebSockets (server and client side) I'm not very familiar with the IETF's efforts, but my understanding is that they were creating a competing protocol. Are they in fact creating something that they want to submit as a replacement to WebSockets? If so, why is WebSockets moving to last call? I'm not necessarily against this change, just confused by it. * On Fri, Nov 13, 2009 at 10:03 AM, Alexey Proskuryakov a...@webkit.orgwrote: While WebSocket API is fairly stable, the discussion of underlying protocol at IETF is far from being done. It could be disruptive to ship our WebSocket implementation in a way that would effectively freeze the protocol. One way to achieve future compatibility is by using a different scheme for WebSocket URLs - e.g. webkit-ws: and webkit-wss: instead of ws: and wss:, respectively. Depending on how protocol standardization goes, we could alias these later, or add a separate standards compliant implementation. I'm going to submit a patch to this effect, but would like to discuss the idea on the list first. - WBR, Alexey Proskuryakov ___ 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] Staging WebSocket protocol deployment
On Fri, Nov 13, 2009 at 3:01 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 13 Nov 2009, Jeremy Orlow wrote: I'm not very familiar with the IETF's efforts, but my understanding is that they were creating a competing protocol. Are they in fact creating something that they want to submit as a replacement to WebSockets? If so, why is WebSockets moving to last call? The IETF is just a bunch of open mailing lists, there's no they that doesn't include us. Sorry I wasn't clear in my word choice. I'm actually on one of the lists, though I obviously don't follow it too closely. :-) The WebSocket protocol is pretty stable at this point. I doubt it will change much. The recent IETF meeting indicated that most people agree that we want something like WebSockets, and it has already received several years of public review. I wouldn't worry about changing the schemes or anything like that; if the protocol _does_ change in non-backwards-compatible ways, then we'll just change the protocol to not step on this code. Just to be clear, you're saying that it's fairly unlikely that it's going to change in a backwards compatible way? I ask because there's not much time left to make such decisions before it goes into Chrome 4 without the webkit- prefix. And once that ship sails, there's not much of a point to adding it. J ___ 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 Fri, Nov 13, 2009 at 3:49 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Nov 13, 2009 at 3:01 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 13 Nov 2009, Jeremy Orlow wrote: I'm not very familiar with the IETF's efforts, but my understanding is that they were creating a competing protocol. Are they in fact creating something that they want to submit as a replacement to WebSockets? If so, why is WebSockets moving to last call? The IETF is just a bunch of open mailing lists, there's no they that doesn't include us. Sorry I wasn't clear in my word choice. I'm actually on one of the lists, though I obviously don't follow it too closely. :-) The WebSocket protocol is pretty stable at this point. I doubt it will change much. The recent IETF meeting indicated that most people agree that we want something like WebSockets, and it has already received several years of public review. I wouldn't worry about changing the schemes or anything like that; if the protocol _does_ change in non-backwards-compatible ways, then we'll just change the protocol to not step on this code. Just to be clear, you're saying that it's fairly unlikely that it's going to change in a backwards compatible way? I ask because there's not much time left to make such decisions before it goes into Chrome 4 without the webkit- prefix. And once that ship sails, there's not much of a point to adding it. On the other hand, as Ojan pointed out, LocalStorage is a perfect example of an API that was thought to be good and stable that became a disaster. Maybe it is best to put it behind a prefix until we have a better understanding of the beast and some real world implementation experience of the complete stack (not just the part in the browser). +1 for AP's plan. ___ 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 Fri, Nov 13, 2009 at 4:01 PM, David Levin le...@google.com wrote: On Fri, Nov 13, 2009 at 3:49 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Nov 13, 2009 at 3:01 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 13 Nov 2009, Jeremy Orlow wrote: I'm not very familiar with the IETF's efforts, but my understanding is that they were creating a competing protocol. Are they in fact creating something that they want to submit as a replacement to WebSockets? If so, why is WebSockets moving to last call? The IETF is just a bunch of open mailing lists, there's no they that doesn't include us. Sorry I wasn't clear in my word choice. I'm actually on one of the lists, though I obviously don't follow it too closely. :-) The WebSocket protocol is pretty stable at this point. I doubt it will change much. The recent IETF meeting indicated that most people agree that we want something like WebSockets, and it has already received several years of public review. I wouldn't worry about changing the schemes or anything like that; if the protocol _does_ change in non-backwards-compatible ways, then we'll just change the protocol to not step on this code. Just to be clear, you're saying that it's fairly unlikely that it's going to change in a backwards compatible way? He's saying if the protocol changes to be incompatible, then it will no longer be ws:, wss: Yes, but once a browser ships ws/wss then we're stuck with that version of the protocol. If it starts to catch on, then browsers will need to implement it for a very long time to come. That's what happened with LocalStorage. By using webkit-ws/webkit-wss we're giving ourselves some wiggle-room until we're sure we're happy with the protocol. And I'm not convinced that we'll know whether we're happy until we have some data from real-world use of WebSockets. (Which should start coming in soon after Chrome 4 ships.) I ask because there's not much time left to make such decisions before it goes into Chrome 4 without the webkit- prefix. And once that ship sails, there's not much of a point to adding it. J ___ 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
I don't buy that at all. There's plenty of features with the webkit- prefix and I think it's pretty clear to developers what that means. On Fri, Nov 13, 2009 at 5:43 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 13 Nov 2009, Jeremy Orlow wrote: By using webkit-ws/webkit-wss we're giving ourselves some wiggle-room until we're sure we're happy with the protocol. Not really. It just means that we might end up stuck with webkit-ws: instead of ws:. -- 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] 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] Staging WebSocket protocol deployment
I think 3 sounds best. 4 seems reasonable. If we need to go with 1 or 2, we should talk to Mozilla to decide whether to standardize on the x or use our own prefixes. If we go with option 3, I think a WebKit blog post would be a good way to make out intentions for WebSockets clear. On Wed, Nov 18, 2009 at 4:38 AM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.orgwrote: 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 ___ 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 1:17 PM, Alexey Proskuryakov a...@webkit.org wrote: On 30.11.2009, at 9:55, Dimitri Glazkov wrote: If we really want to move the Web platform forward, we can't afford a feedback cycle this long. Per http://webkit.org/projects/goals.html, it doesn't seem that we want this at all, much less really want. You're twisting words. We (everyone working on WebKit) do really want to move the web platform forward, it's just that we don't always agree how best to do that. First of all, 2 major points: There are plenty of experiments that have been done in the WebKit code base that haven't been agreed upon in standards bodies or on webkit-dev before hand, and we should have a high standard for the experiments done and should only do them when we do think there's a strong possibility of a standardized future. In this case, the idea was floated around both standards bodies and webkit-dev. The response we got from the standards mailing list was some skepticism but a someone should experiment with this and see how useful it is type response. There are a lot of people inside Google that have a lot of experience with web standards, browsers, and web apps that seem to think this is useful and worth the effort to experiment with it. Some of these people are even WebKit reviewers and are volunteering to take on the burden of implementing the experiment. If that's not enough, then I'd say we need to come up with some formal criteria on what types of non-standard experiments are OK and what aren't. J ___ 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 1:45 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 30, 2009, at 9:55 AM, Dimitri Glazkov wrote: Reading this, I am reminded of a great commentary by Alex Russell, written nearly 3 years ago: http://alex.dojotoolkit.org/2007/12/the-w3c-cannot-save-us/ Despite of what I may think about SharedScript, I am certain that waiting -- whether for standards community or Web developers to embrace or reject our ideas -- is not the right answer. If we really want to move the Web platform forward, we can't afford a feedback cycle this long. Especially, when we have an opportunity for close collaboration with Web developers of some of the most JS-intensive Web properties. Experimenting is great. We should experiment. WebKit (or at least the mainline) is not necessarily a great place for experiments. As our Project Goals say: WebKit is an engineering project, not a science project. http://webkit.org/projects/goals.html. Of course, that's a pretty fuzzy line, because sometimes a use case is really well proven and we're not willing to wait for standards groups to get their butt in gear. But there are some potential bad scenarios with building features that don't have a clear path to standardization: 1) It will be rejected by other browser vendors and end up a WebKit-only (or nearly WebKit-only) feature, but enough WebKit-specific content depends on it that we can't drop it, even if we would like to. Then we are stuck maintaining a dead-end technology indefinitely. It seems like the SQL database may be on this path. 2) It will get adopted into standards, but with significant changes when other implementors and standards experts jump on the bandwagon. These changes can cause a very painful transition, since we need to remain compatible with legacy WebKit-specific content, yet at the same time we don't want to be in violation of the consensus spec. This actually happened with canvas - it changed incompatibly in ways that broke a bunch of WebKit-specific content (in particular Dashboard widgets), but we had to implement the standard to support content coded to Firefox. This really sucked and we have Dashboard-specific hacks still lying around in our code base as a result. So please realize, experimenting is not free. The cost can be much greater than the implementation cost, and may indeed last far beyond the experimental era. These kinds of bad scenarios are the reason that nowadays we try to get standards buy-in on new Web platform features *before* they get shipped in a mass-market product. And experience with these kinds of scenarios is what makes some of us very wary of going hog-wild with experiments in the WebKit code base. We take backwards compatibility for Web content very seriously, and so we hesitate to put anything in that we don't feel we can commit to. Isn't it being developed behind a flag? If not, couldn't it be? That would keep it from being inadvertently shipped with any platforms. If there is a compatibility breaking burden, it would be those who explicitly choose to ship it, and those alone. As far as I can tell, the only thing at issue here is the code maintenance burden. Other embedders of WebKit should be shielded from the other issues you cite. ___ 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 1:54 PM, Geoffrey Garen gga...@apple.com wrote: There are a lot of people inside Google that have a lot of experience with web standards, browsers, and web apps that seem to think this is useful and worth the effort to experiment with it. Who exactly inside Google is waiting to build a new service, feature, or experiment using SharedScript? I don't think we can or should have to say specifically, but several major apps with millions of users. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GlobalScript in WebKit
Does anyone have a link to the spec? On Mon, Nov 30, 2009 at 4:07 PM, Oliver Hunt oli...@apple.com wrote: 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. Multi-process browsers are bringing more complexity (and benefits). Not all technical issueshttp://www.chromium.org/developers/design-documents/process-modelsare completely resolved in Chrome's implementation, and we might need (or not) some mechanism of saying that a bunch of pages form an application and should share a process. Right now, it's unclear if such mechanism even needed though. I agreed with you to remove the implementation details from the doc because indeed they do not belong there. Not that they are not existing. For example, the fact that in Chrome SharedWorkers are indeed inter-process theoretically could be different. WebWorkers spec does not specify where and how to look for instances of SharedWorkers, although it implies some useful degree of sharing. The fact that in Chrome they are shared across all processes is a detail of Chrome implementation. The Worker implementation behaviour is not really relevant to this conversation. The issue is whether a browser implements a spec in a correct manner, that's why implementation is not described. A worker for instance may be per thread, per process, or may not even represent a separate machine thread and could be implemented by in software just running each task in sequence (assuming a sufficiently careful implementation, etc, etc). The issue we're discussing however was what Darin bought up -- should a multiprocess browser be allowed to have multiple distinct instances of the same Global/SharedScript? the answer is clearly no (and that concept has been removed from the spec); I don't agree that it's clearly no and I didn't have any clue that it had been removed from the spec. If multiple processes/event-loops would share the same SharedScript instance then we're either not going to be able to maintain run to completion semantics or its going to need to use the storage mutex (which would probably need to be renamed). That would be unfortunate to put it very...VERY lightly. The issue being that in regular day to day use such a browser could end up producing behaviour inconsistent with behaviour that of browsers that actually did provide a single shared context -- in effect all users of Global/SharedScript would have to assume that their Global/SharedScript context was not in fact shared. The resultant implication is that a Shared or Global script would have not need to be shared at all and each page could have it's own copy -- effectively degenerating to a glorified iframe. I would consider it to be a warning sign of potential badness in a spec if behaviour was being defined by perceived difficulty in implementing a feature, rather than on the desired end user behaviour. In general I feel a spec should always favour complexity of implementation over complexity in use, after all if a feature is hard to implement it still only needs to be implemented a relatively small number of times (basically once per browser/engine) pushing the complexity on to end developers however then means thousands (millions?) of developers have to implement the same code and deal with the same complexity over and over again. Obviously if there's an option to avoid any complexity that would be best, but i suspect that's unlikely to exist :-D --Oliver Dmitry On Mon, Nov 30, 2009 at 3:08 PM, Geoffrey Garen gga...@apple.com wrote: Just a note: In Chrome, a SharedWorker is reachable from any WebKit process, whereas a SharedScript would only be reachable within a WebKit process. This is an interesting distinction, and I can imagine some use cases for SharedWorker that SharedScript could not address. (This distinction arises because we did not want to build a script proxy between WebKit processes as that would be quite costly.) For example, suppose you wanted to have only one instance of a web app responsible for manipulating a database or communicating with a server. There's no guarantee that multiple instances of a web app would all run in the same WebKit process. Actually, I objected to that distinction, and it has been removed
Re: [webkit-dev] GlobalScript in WebKit
On Mon, Nov 30, 2009 at 4:29 PM, David Levin le...@google.com wrote: On Mon, Nov 30, 2009 at 4:15 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 30 Nov 2009, Dmitry Titov wrote: That also pretty much means if we won't do SharedScript, we'll need to explore other opportunities toward efficient sharing of code and data which does not make people to write a multithreaded UI as SharedWorker solution would do. We have practically zero positive response to SharedWorkers being used this way. Granted, this is just one company but the limited unscientific poll kind of shows the direction... The pushback on SharedWorkers at Google is because Google teams don't want to rewrite their apps to work with workers -- SharedScript lets them handle some of the cases SharedWorkers would get them, without having to rewrite as much code. Presenting this as a SharedWorker vs SharedScript thing is a false dichotomy. SharedWorkers and SharedScript serve different purposes for the people who want to use each. The majority of applications are not written to do *all* of their logic in a background thread, so it is odd to me that it is espoused as the right paradigm on web developers. There is a certain amount of logic that makes sense to happen on the main thread and be shared across windows. However, we should not be basing the platform's progress on transition cost avoidance of one company. Google can afford to rewrite GMail if it comes down to that. It is not in the Web's long term interests for us to design features that are optimised for the transition phase at the cost of the long-term health of the Web. On the other hand, just because there is a hammer, it doesn't mean that everything is a nail no matter how much we want it to be. What we should be looking at is what API do teams prefer to work with when starting from scratch, And it makes a lot of sense for new apps to do some logic that is quick on the main thread (and not proxy it off to another thread). because on the long term that will be the far more common case than transitioning from a legacy codebase. I don't think that our (Google's) response is representative here. Based on my 10+ years of experience as an app developer, I think the response is very representative of what I'd want. To be fair, app developers in general want to do everything synchronously but we (in standards land) have pushed back very hard because software research has shown that such interfaces are very difficult (if not impossible) to parallelize. That's why SharedScript sidesteps the issue by saying there should be no parallelism. Which really is a step backwards. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedScript/Worker and multiprocess browsers
On Mon, Nov 30, 2009 at 5:05 PM, Oliver Hunt oli...@apple.com wrote: Sorry, I think you misunderstand. The way Chrome processes are divided is an implementation detail, but it is an important one. I think it is folly to ignore it when designing web APIs. We'll likely *never* implement APIs that involve cross-process, synchronous script evaluation. We have some experience with that in supporting plugins, and I can tell you that I do not favor it: not just because of implementation complexity but also because of the performance impact it entails. It is wrong to design an API based on architectural decisions of your existing browser -- you should be making decisions based on what the developers actually need. Being hard for the browser to implement is a secondary concern next to being hard for the end developer to use. The issue being that in regular day to day use such a browser could end up producing behaviour inconsistent with behaviour that of browsers that actually did provide a single shared context -- in effect all users of Global/SharedScript would have to assume that their Global/SharedScript context was not in fact shared. This is true, but I don't think it is a big deal. Processes are roughly divided up into browsing units. You start a new browsing unit by opening a new tab and navigating it. By doing so, you are creating a separate world that cannot see other worlds. SharedWorkers (as well as cookies and other storage mechanisms) provide a bridge between these worlds, but window.open and SharedScripts do not (b/c of the script connection they imply). I have a (simple) question: If Global/SharedScript is not guaranteed to be either Global or Shared, what is it trying to accomplish? It's not possible for any developer to use them for shared state as they can't guarantee that a normal user, doing normal things, is not going to end up with distinct instances of this shared state. Please look at the use cases in the spec. They're pretty much all an optimization to cut down on resource utilization and load times by sharing more state. As a side note, I would expect that many SharedScript users would also use SharedWorkers for a lot of the non-UI logic including storage and network. Also note that the possibility of having multiple SharedScript instances within one browser is pretty much the same as the possibility of the user having multiple browsers open on the same computer. ___ 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 5:37 PM, Dmitry Titov dim...@chromium.org wrote: On Mon, Nov 30, 2009 at 5:21 PM, Maciej Stachowiak m...@apple.com wrote: By the way, we could enable the SharedScript programming model at much lower WebKit-level implementation cost and with much less API surface as follows: - Allow Window to be passed via the structured clone algorithm over a MessageChannel, but it throws on all access if the recipient is not same-origin, in the same thread, and eligible for synchronous calls (i.e. in the same process). I believe this would allow SharedScript to be implemented in JavaScript. Essentially you'd use a SharedWorker to coordinate and elect a leader Window within each same-process group, which could then create a JavaScript object which it vends to all other Windows. The object does not get GC'd until all the referencing windows go away. Yep, a variants of this were proposed... One difficulty with this is that while JS object is kept alive, the interesting objects like timers, XHR, WebSockets die once leader Window is closed. With the exception of timers, most of these things would also suffer from network errors. I wonder if the same code could be used to recover from them. In addition, everything you mentioned would be a good use case for a SharedWorker since it'd be fairly detached from UI and is async. Plus, the leader [re]election algorithm should be implemented. It is not impossible to keep track of enough things to fix up the context, but it is way too difficult and error-prone. It sounds like by making it easier with SharedScript we'd remove the burden of those implementations from many web developers. Just connect to it and it provides stable JS context for things to run in. If we go with this, I believe we'll need to follow up with things like making XHR work even if page created it was closed... It might end up being essentially the same as SharedScript itself. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedScript/Worker and multiprocess browsers
On Mon, Nov 30, 2009 at 5:58 PM, Oliver Hunt oli...@apple.com wrote: On Nov 30, 2009, at 5:40 PM, Jeremy Orlow wrote: On Mon, Nov 30, 2009 at 5:05 PM, Oliver Hunt oli...@apple.com wrote: Sorry, I think you misunderstand. The way Chrome processes are divided is an implementation detail, but it is an important one. I think it is folly to ignore it when designing web APIs. We'll likely *never* implement APIs that involve cross-process, synchronous script evaluation. We have some experience with that in supporting plugins, and I can tell you that I do not favor it: not just because of implementation complexity but also because of the performance impact it entails. It is wrong to design an API based on architectural decisions of your existing browser -- you should be making decisions based on what the developers actually need. Being hard for the browser to implement is a secondary concern next to being hard for the end developer to use. The issue being that in regular day to day use such a browser could end up producing behaviour inconsistent with behaviour that of browsers that actually did provide a single shared context -- in effect all users of Global/SharedScript would have to assume that their Global/SharedScript context was not in fact shared. This is true, but I don't think it is a big deal. Processes are roughly divided up into browsing units. You start a new browsing unit by opening a new tab and navigating it. By doing so, you are creating a separate world that cannot see other worlds. SharedWorkers (as well as cookies and other storage mechanisms) provide a bridge between these worlds, but window.open and SharedScripts do not (b/c of the script connection they imply). I have a (simple) question: If Global/SharedScript is not guaranteed to be either Global or Shared, what is it trying to accomplish? It's not possible for any developer to use them for shared state as they can't guarantee that a normal user, doing normal things, is not going to end up with distinct instances of this shared state. Please look at the use cases in the spec. They're pretty much all an optimization to cut down on resource utilization and load times by sharing more state. As a side note, I would expect that many SharedScript users would also use SharedWorkers for a lot of the non-UI logic including storage and network. Also note that the possibility of having multiple SharedScript instances within one browser is pretty much the same as the possibility of the user having multiple browsers open on the same computer. The point i was getting at is that unlike the typical way to get this situation (running multiple browsers) is not a common end user behaviour, but Chrome's model makes it very easy -- as far as I am aware if I open two windows independently and navigate both to example.com i will end up with two processes, thus ending up with two instances of the same SharedScript. I actually just did a quick test, and I am unsure how I can actually open two windows in such a way that Chrome would end up using a single SharedScript instance -- both new window and new tab result in separate processes, the only logical case that would allow multiple windows to end up sharing an instance (and thus gaining any benefit at all from this feature) would be by opening a window from an original source page, in which case an invisible iframe could trivially be passed around, and has all of the advantages of SharedScript, none of the disadvantages, and works in all existing browsers. The usage of SharedScript is a strong hint to the browser that future tabs for that origin should be opened in the same process. With such a heuristic, you only run into trouble when a particular origin doesn't immediately use the SharedScript and a user opens up another tab in the mean time. This could be mitigated by the browser saving which origins use SharedScript somewhere. Has anyone really sat down and compared the use cases given in the spec to the behaviour of users? eg. to see if the model you're talking about would actually provide any real benefit in real world usage The spec was co-written by real world users (gmail engineers). ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedScript/Worker and multiprocess browsers
On Mon, Nov 30, 2009 at 6:31 PM, Oliver Hunt oli...@apple.com wrote: Has anyone really sat down and compared the use cases given in the spec to the behaviour of users? eg. to see if the model you're talking about would actually provide any real benefit in real world usage The spec was co-written by real world users (gmail engineers). Engineers are not everyday users -- I am not referring to developers (i've been fairly careful in this discussion to not conflate developers with end users), I am referring to actual end users and their interaction with the browser. If a SharedScript is meant to indicate that a new process shouldn't been spawned it seems reasonable to require SharedScripts actually be shared. The end user benefit is lower latency and resource usage. If you click the link in gmail to tear off a chat window or compose email window there's (very) user noticeable latency. Some of this we can continue to improve with browsers, but it's not easy and it will definitely be a while before an app like gmail can be loaded in 100ish ms (so it's not perceivable). And some (resource sharing) is nearly impossible without help from the app. On Mon, Nov 30, 2009 at 6:34 PM, Charles Reis cr...@chromium.org wrote: The usage of SharedScript is a strong hint to the browser that future tabs for that origin should be opened in the same process. With such a heuristic, you only run into trouble when a particular origin doesn't immediately use the SharedScript and a user opens up another tab in the mean time. This could be mitigated by the browser saving which origins use SharedScript somewhere. [from the right email address] Just my two cents, but I don't think the browser's process model should change based on a web site's use of SharedScript. This would end up causing all of the instances of a given web site to share a process, which can have bad implications for responsiveness. (Basically, it eliminates most of the benefits of having a multi-process browser if the user visits a lot of pages from the same site.) I haven't been following the SharedScript discussion closely enough, but I was under the impression that it was mainly targeted at pages opened directly from existing pages. If the user creates separate windows and navigates them to the same site independently, I would argue that those should not share the same SharedScript. The main purpose of SharedScript is to make web apps more single threaded (and thus able to share more state). Besides the whole site crashing when one tab of it crashes, I don't really see any problem with having the whole app in the same processthat's essentially what's being asked of us. If we're only targeting opening new windows via script, then there's really no reason to do SharedScript since the windows can already access each other. You can even do clever things so that children of children still can communicate even if one of the middle nodes gets closed. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
