Re: [webkit-dev] Multiprocess networking in WebKit
About MemCache considerations, you list these options... * Do not share storage * Share storage but hits in remote caches are asynchronous * Share storage and all cache hits are serviced synchronously Is there a fourth option? * Share storage and all cache hits are async in all cases (the resulting handle is returned asyncly, but the data is then directly addressable). And then maybe a fifth two-tiered option that builds on the above to get to something more satisfying? * Shared storage is accessible asyncly at the level of ResourceHandle (that fourth option). * Local handles to shared resources are accessible syncly at the level of todays MemCache, where the local memcache gets populated with handles to resources in shared storage. I'm merrily ignoring how decoded data is also associated with CacheResources (and how it can mutate depending on attributes of the Document for which it was most recently decoded). On Mon, Dec 3, 2012 at 4:16 PM, Adam Barth aba...@webkit.org wrote: There's been a somewhat fragmented discussion across webkit-dev and various bugs about how we ought to approach multiprocess networking in WebKit. In an attempt to organize my thoughts, I wrote up a short design document that compares various approaches: https://docs.google.com/document/d/1ihpwbiG_EDirnLibkkglEtyFoEEcf7t9XNAn8JD4fQY/edit My hope is that this document will be useful as a starting point for discussion. If other folks have written similar documents, those might make valuable contributions to the discussion as well. I welcome your feedback, either via comments in the document or via this email thread. Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Notifications for Blob serialization/deserialization
On Tue, Jul 3, 2012 at 4:08 PM, Greg Billock gbill...@google.com wrote: Do you think the way my patch does this, by exposing two new methods on the BlobController for notifying serialization and deserialization, will be sufficient? For IndexedDB, it looks to me that notifications like this (or on the BlobData ID, as you propose) will be critical -- the IndexedDB will need to read the blob values to store them, at which time it can release the refs it holds. The math won't work out unless it can know that the ref it just deleted was given to it in serialization, which my notifier would accomplish. Similarly for history -- if history supports Blob, then packaging that serialization needs to hold the refcount. All these use cases amount to the same thing: use of a serialized Blob outside the normal usage of creation/deletion within a single context. I think we're all in agreement that Blob semantics according to the spec should support this use case, even if Blob URLs explicitly don't. Do you want to revamp the management API to use BlobData IDs before adding a pair of de/serialization APIs? If we do, we can skip some of the nastiness here, like managing an extra serialization internal URL. It'll definitely be easier to see. If that's going to take a while, though, I'd like to get a preliminary solution in place so web intents can use blobs. I'd vote to decouple proximate fixes from general revampage if possible so we don't hold worthy capabilities hostage to housecleaning. Being able to utilize blobs in webintent payloads seems pretty valuable. Who's a good person to ask about the history API's support (or lack thereof) of Blobs? Thnx for pointing out the the pushstate / history use-case, i didn't know about that one. I'm not sure who all knows about that? On Tue, Jun 26, 2012 at 2:54 PM, Michael Nordman micha...@google.comwrote: I think revamping our Blob handling is one of the projects that I should be working on next. What we have now is proving to be too difficult to work with in a variety of ways. The more i look at this particular difficulty with sending blobs within serialized values (within chromium), the more convinced i am that we should switch to identifying the 'data underlying a blob' rather than the 'blob object instance'. Currently our 'ids' identify a WebCore::Blob instance. The trouble with putting ids on blob object instances is that they dont cross process boundaries, so we end up either trying to create the id in advance of the instance in some other process, or relying on the originating instance still being around when the new instance in the other process gets coined (based on the originals ids). We have to juggle 2 ids instead of one and conceptually its just a mess. What I'm thinking about is changes along these lines... * WebCore::Blobs have an 'id' that refers to the 'data'. At ctor and dtor time, they increment/decrement a refcount, via ipcs, on the underlying 'data' in the main browser. A clone or copy of that WebCore::Blob instance anywhere in the system will carry that same 'id' and do that same refcounting of the underlying data. * When a IPC message containing a serialized blob (the id value) is in transit, extra refs are applied to the underlying blob data. There are several cases where we need to consider a blob as 'in transit'. Being referred to in an WebCore::SSV is one place. Being referred to in a content::SSV is another. As those objects come and go, they should inc/dec any blobs they refer to accordingly. A content::SSV has to distinguish between running in the main browser process and a child process to do that properly. * A challenging case is when sending SSVs containing blobs from the browser process to a child (renderer|worker) process. After a message is put on the wire going that direction, its not safe to deref the blob data until the receiving side has picked it up and added a ref of its own. I think we'll need ACKS for messages flowing in that direction so the browser-side knows when its safe to drop the extra in transit ref. * Its easier going the other way, from child to browser, since if the child has a ref when the 'id' is put on the wire, that ref cant possibly be removed prior to that msg reaching the browser. Not sure how much of this disccusion affects webkit's native blob handling really? This whole chromium multi-process problem doesn't exist there. I think we can put high level abstractions in webcore that we then fork at that high level... and the forked chromium impl deals with the complexities in our multi-process case w/o impatcing webcore's native single process impl. Another source of difficulty stems from how the ThreadableBlobRegistry posts all operations to the 'main' webkit thread. That's not going to work very well with how we handle IDB operations entirely from the 'context' thread even if its a background worker context. Message sent
Re: [webkit-dev] Notifications for Blob serialization/deserialization
I think revamping our Blob handling is one of the projects that I should be working on next. What we have now is proving to be too difficult to work with in a variety of ways. The more i look at this particular difficulty with sending blobs within serialized values (within chromium), the more convinced i am that we should switch to identifying the 'data underlying a blob' rather than the 'blob object instance'. Currently our 'ids' identify a WebCore::Blob instance. The trouble with putting ids on blob object instances is that they dont cross process boundaries, so we end up either trying to create the id in advance of the instance in some other process, or relying on the originating instance still being around when the new instance in the other process gets coined (based on the originals ids). We have to juggle 2 ids instead of one and conceptually its just a mess. What I'm thinking about is changes along these lines... * WebCore::Blobs have an 'id' that refers to the 'data'. At ctor and dtor time, they increment/decrement a refcount, via ipcs, on the underlying 'data' in the main browser. A clone or copy of that WebCore::Blob instance anywhere in the system will carry that same 'id' and do that same refcounting of the underlying data. * When a IPC message containing a serialized blob (the id value) is in transit, extra refs are applied to the underlying blob data. There are several cases where we need to consider a blob as 'in transit'. Being referred to in an WebCore::SSV is one place. Being referred to in a content::SSV is another. As those objects come and go, they should inc/dec any blobs they refer to accordingly. A content::SSV has to distinguish between running in the main browser process and a child process to do that properly. * A challenging case is when sending SSVs containing blobs from the browser process to a child (renderer|worker) process. After a message is put on the wire going that direction, its not safe to deref the blob data until the receiving side has picked it up and added a ref of its own. I think we'll need ACKS for messages flowing in that direction so the browser-side knows when its safe to drop the extra in transit ref. * Its easier going the other way, from child to browser, since if the child has a ref when the 'id' is put on the wire, that ref cant possibly be removed prior to that msg reaching the browser. Not sure how much of this disccusion affects webkit's native blob handling really? This whole chromium multi-process problem doesn't exist there. I think we can put high level abstractions in webcore that we then fork at that high level... and the forked chromium impl deals with the complexities in our multi-process case w/o impatcing webcore's native single process impl. Another source of difficulty stems from how the ThreadableBlobRegistry posts all operations to the 'main' webkit thread. That's not going to work very well with how we handle IDB operations entirely from the 'context' thread even if its a background worker context. Message sent on behalf of blobs take a longer slower route to reach our main browser process than those sent on behalf of IDB, so an IDB message that contains a blob id may reach the main browser prior to the blob messages that create that blob reach the main browser. I think we have to avoid going thru the 'main' webkit thread in the chromium port for the blob handling messages to avoid odd races. On Tue, Jun 26, 2012 at 11:03 AM, Joshua Bell jsb...@chromium.org wrote: On Tue, Jun 26, 2012 at 10:19 AM, Greg Billock gbill...@google.comwrote: I've been working with Michael Nordman on a problem related to Blob serialization. Currently, if we serialize a Blob, there's no notification to the BlobRegistry, so the serialized Blob will be garbage collected at an indeterminate time if the context in which it was created is closed. This lifetime scoping is spelled out clearly for Blob URLs created using the URL API. I see nothing in the spec imposing the same lifetime scoping on Blobs themselves, so I think it is an implementation flaw. To correctly handle this serialization case, however, the BlobRegistry needs to know when serialization and deserialization operations happen for Blob objects. I've created a patch that adds that logic and plumbs it through to the Chromium API. Webkit patch: https://bugs.webkit.org/show_bug.cgi?id=89921 The corresponding Chromium-side patch is here: http://codereview.chromium.org/10662024/ The strategy I used is to create a new internal URL and use that for serialization: KURL cloneURL = BlobURL::createInternalURL(); blobRegistry().didSerializeBlob(cloneURL, blob-url()); m_writer.writeBlob(cloneURL.string(), blob-type(), blob-size()); m_blobURLs.append(cloneURL.string()); Then upon deserialization, there's a corresponding didDeserializeBlob call. There are a couple alternatives I considered. One is to not instrument the SerializedScriptValue this way, but require
Re: [webkit-dev] run-webkit-tests is moving to parallell testing by default (this weekend)
Some http tests make use of stateful php scritps with different tests utlizing the same scripts in some cases. Does each 'worker' get a dedicated http server instance or do they share the same http server? On Mon, Dec 5, 2011 at 1:01 PM, Dirk Pranke dpra...@chromium.org wrote: We never implemented the general way of marking subdirectories as needing to run serially, but it would be easy to do if we needed to [the 'http' dirs are still special-cased in the code]. There is code now (landed a few months ago) to control how many http tests run in parallel separately from the main parallelism flag (so you can run 16 workers but only 2 http tests at a time). I implemented it but never flipped the switch because it was in the middle of Eric flipping the bots over to NRWT in the first place. We should try experimenting with this to see at some point once everything stabilizes otherwise (this is the max_locked_shards() call in manager.py; there's no command line flag). -- Dirk On Mon, Dec 5, 2011 at 11:17 AM, Ojan Vafai o...@chromium.org wrote: Why is that? I don't know about other ports, but AFAIK, chromium writes to a mock clipboard and the Apple mac port writes to a local OS clipboard instance instead of the global one, specifically to avoid copy/paste tests interacting. Even without running tests in parallel, it's probably a good idea in order to avoid copy-pastes the developer is doing from affecting the test run. That said, I believe we have a general way of marking subdirectories as needing to run serially (which is what we do for http) if there are other reasons we need to. On Mon, Dec 5, 2011 at 11:12 AM, David Levin le...@google.com wrote: I believe there are some tests (copy/paste) that it would be very hard to fully shard due to how they work. dave On Mon, Dec 5, 2011 at 11:08 AM, Ojan Vafai o...@chromium.org wrote: I looked at one example that didn't exit early: http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28Tests%29/builds/35153/steps/layout-test/logs/stdio In that case, the http tests were the long tail and took 6 minutes longer than all the other tests. We don't split the http tests up because every time we've tried it's caused too much flakiness. It's unclear if the flakiness points to a bug in the test harness (e.g. in how we setup apache) or to bugs in the tests themselves or both. If someone has time to look into this, this is probably the biggest benefit to be found in NRWT runtime when running tests in parallel. FYI, NRWT outputs a log of the runtime after each run: 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/9: 4696 tests, 1746.63 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/8: 1177 tests, 1693.47 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/3: 1408 tests, 2033.51 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/2: 941 tests, 2119.65 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/1: 1121 tests, 2041.97 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/0: 1453 tests, 2515.75 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/7: 1189 tests, 1731.12 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/6: 3556 tests, 2114.37 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/5: 948 tests, 2097.13 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/4: 1411 tests, 1716.66 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/15: 795 tests, 2027.16 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/14: 1123 tests, 1732.72 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/13: 425 tests, 2021.25 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/12: 1175 tests, 1710.09 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO worker/11: 3462 tests, 2096.30 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO worker/10: 1449 tests, 1722.68 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO31120.45 cumulative, 1945.03 optimal That shows you that, if we fully sharded all the tests, they would in theory take 1945 seconds to run, but worker/0 (the worker that runs the http tests) took 2515 seconds to run. Ojan On Mon, Dec 5, 2011 at 6:55 AM, Adam Roben aro...@apple.com wrote: On Dec 2, 2011, at 6:55 PM, Eric Seidel wrote: The SnowLeopard bot went from a 1 hr 4 min (!?!) cycle time, to 38 min (still !?!). I suspect our Mac test bots could use a dose of RAM. Many of them only have 3GB, since when you're running tests one by one you don't really need much more. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org
[webkit-dev] Custom exception messages for IDL defined methods that raise DOMException.
I have a case where given an IDL defined method thats defined to raise a DOMException, I'd like to set a custom exception message from within the webcore implementation and have that message percolate up into script via the bindings layer(s) and be accessible as the exception.message attribute. I don't see a non-custom way of doing that and am wondering if there should be support for something like this w/o having to resort to custom bindings? The particular methods I'm looking at are the openDatabase(...) method of DOMWindow and WorkerContext, but this seems like it might be useful in other cases as well. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Custom exception messages for IDL defined methods that raise DOMException.
On Mon, Nov 14, 2011 at 5:17 PM, Adam Barth aba...@webkit.org wrote: For SQLException, there are a hundred exception codes reserved, static const int SQLExceptionOffset = 1000; static const int SQLExceptionMax = 1099; of which, we appear to only be using eight. It sounds like you're considering exposing more than a finite enumerated number of error codes, however. Do we really want to make SQLite error messages part of the web platform? What if we want to upgrade to a newer version of SQLite in the future (which might have different error codes)? IMHO, we shouldn't be investing much more effort into WebSQLDatabase. It's something of a dead-end for the platform. If you're set on investing more effort, one path forward is to figure out which are the most important kinds of errors to distinguish and to give them error codes. You can then give them descriptions as usual without needing any custom bindings. I don't want to change the set of exception 'codes' really. There are significant clients of WebSQL. They can't transition to IDB until it's up to the task and they've made that transition. For the time being, I'm willing to better support websql. There are a errors in the wild and figuring out what errors are important isn't as easy as it sounds. See http://code.google.com/p/chromium/issues/detail?id=98939 about INVALID_STATE_ERR: DOM Exception 11. I'd like to be able to determine two things given the exception... callsite in webcore that failed and the sqlite error code seen at that callsite. That would make for a large number of new codes. If there's no general case for returning a custom message, a reasonable option for me may be to use [custom] bindings for these methods and to have that custom binding set the exception message attribute accordingly. Adam On Mon, Nov 14, 2011 at 4:58 PM, Michael Nordman micha...@google.com wrote: I guess the exception of interest is SQLException. Take a look at Database.cpp line 103. The ' errorMessage' string on that line contains more detailed information about what went wrong in the act of opening the database, including things like an sqlite error code and sqlite error message. These strings are formed in the bowls of AbstractDatabase::performOpenAndVerify(). On Mon, Nov 14, 2011 at 4:48 PM, Adam Barth aba...@webkit.org wrote: I'm not sure exactly what you're trying to do, but one option is to add a new type of DOMException: http://trac.webkit.org/browser/trunk/Source/WebCore/dom/DOMExceptions.in Another option is to customize the message from an existing exception (here are the DOMCore exceptions): http://trac.webkit.org/browser/trunk/Source/WebCore/dom/DOMCoreException.cpp If you show me the spec you're trying to implement, I might have a more concept suggestion of the best way to implement it. Adam On Mon, Nov 14, 2011 at 4:44 PM, Michael Nordman micha...@google.com wrote: I have a case where given an IDL defined method thats defined to raise a DOMException, I'd like to set a custom exception message from within the webcore implementation and have that message percolate up into script via the bindings layer(s) and be accessible as the exception.message attribute. I don't see a non-custom way of doing that and am wondering if there should be support for something like this w/o having to resort to custom bindings? The particular methods I'm looking at are the openDatabase(...) method of DOMWindow and WorkerContext, but this seems like it might be useful in other cases as well. ___ 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] Custom exception messages for IDL defined methods that raise DOMException.
I sure hope specific exception messages are not getting codified in specs. I don't see where the discussion of other browsers is relevant becaus it's pretty clear other impls of this component aren't going to happen, yet this remains a useful feature of webkit/chrome for the time being. It has issues and i'd like to make it more useful. From a practical point of view, without being able to observe what error conditions are actually arising makes improvements is more difficult. My thought was to expose information about that to developers which would also make its way back to us. There are a number of APIs that accept 'errorCallbacks', the messages delivered to those callbacks already contain more detailed messages. At this point I'm looking at improving the reporting for methods that directly throw exceptions. Most notable is the openDatabase() method. A more detailed message is being logged to the console, but i'd like that to be more directed into the hands of the callers of that method. Afaict, the platform does define a means of expressing exceptional conditions including a means of conveying a message that ideally provides useful information. I'd like to fill in that useful information part, INVALID_STATE_ERR: DOM Exception 11 isn't particularly useful to anyone. Its fair to say INVALID_STATE for many distinct low level error conditions, there's nothing wrong with the API. My intent in starting this thread was to determine the best way of providing a more detailed message. I don't agree that error messages are evil? In the case of websql or indexedDB, where there is a complex backing store of some kind that's likely different across browsers, i think it is helpful to surface useful implementation specific details for diagnostic and debugging purposes. On Mon, Nov 14, 2011 at 5:56 PM, Adam Barth aba...@webkit.org wrote: On Mon, Nov 14, 2011 at 5:41 PM, Michael Nordman micha...@google.com wrote: On Mon, Nov 14, 2011 at 5:17 PM, Adam Barth aba...@webkit.org wrote: For SQLException, there are a hundred exception codes reserved, static const int SQLExceptionOffset = 1000; static const int SQLExceptionMax = 1099; of which, we appear to only be using eight. It sounds like you're considering exposing more than a finite enumerated number of error codes, however. Do we really want to make SQLite error messages part of the web platform? What if we want to upgrade to a newer version of SQLite in the future (which might have different error codes)? IMHO, we shouldn't be investing much more effort into WebSQLDatabase. It's something of a dead-end for the platform. If you're set on investing more effort, one path forward is to figure out which are the most important kinds of errors to distinguish and to give them error codes. You can then give them descriptions as usual without needing any custom bindings. I don't want to change the set of exception 'codes' really. There are significant clients of WebSQL. They can't transition to IDB until it's up to the task and they've made that transition. For the time being, I'm willing to better support websql. There are a errors in the wild and figuring out what errors are important isn't as easy as it sounds. See http://code.google.com/p/chromium/issues/detail?id=98939 about INVALID_STATE_ERR: DOM Exception 11. I'd like to be able to determine two things given the exception... callsite in webcore that failed and the sqlite error code seen at that callsite. That would make for a large number of new codes. The cost of exposing detailed error information is that all browsers that implement WebSQLDatabase will need to generate the exact same errors in the exact same situations. Part of the reason why other browser vendors shot down WebSQLDatabase was that it was too reliant on implementation details of SQLite. Exposing these ad-hoc error states as part of the platform just makes that problem worse, especially if you're talking about a large number of error conditions, as you seem to be. If there's no general case for returning a custom message, a reasonable option for me may be to use [custom] bindings for these methods and to have that custom binding set the exception message attribute accordingly. The issue isn't the best way of implementing this feature, the issue is whether we should be exposing this level of implementation detail to the platform. If we can't abstract the error conditions into a small, finite list, there's very unlikely we'll be able to maintain precisely the same error behavior over time, let alone specify the behavior in sufficient detail and correctness that someone else could implement it precisely the same way. Adam On Mon, Nov 14, 2011 at 4:58 PM, Michael Nordman micha...@google.com wrote: I guess the exception of interest is SQLException. Take a look at Database.cpp line 103. The ' errorMessage' string
Re: [webkit-dev] Gamepad API [Was: New feature flag proposal: Joystick API]
Its obvious that a naming nit is a not a good reason to block development behind a flag. Is the the true basis for that r- expressed in this comment? The concern here as I understand it is that providing low level access to every possible controller creates fragmentation, with purportedly HTML content that only works on a few devices. There is no clear cut border here - it's been mentioned that even touch events can be seen as rare - and then I advocate that adding more mouse specific events is a bad idea for the same reason. But that concern also shouldn't block initial development behind a flag. Seems like that concern should be brought up with the WG. On Wed, Oct 12, 2011 at 12:59 PM, Darin Fisher da...@chromium.org wrote: Hi all, Alexey appears to strongly dislike the name of this API specification ( http://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html), so much so that he is blocking development of the API behind a flag. As a reminder, this API is being developed through the WebEvents WG jointly with other browser vendors, including Mozilla. Folks working on this appear to be content with the Gamepad name, precisely because the spec is limited to dealing with input devices that are represented in terms of buttons and axes. Gamepad seems like a fairly canonical name for such a device, even though devices by other names can be represented by similar data. Does anyone else feel strongly enough that the name of the API is so bad that it should therefore not be allowed onto WebKit trunk behind a flag? Personally, I feel like the name is quite malleable at this point in time, and I really like coming up with the best possible name for things. However, I don't see why we need to have the perfect name before we continue development of this feature behind a flag. As we were developing Blob and File support, we made several name changes along the way. It is not always so obvious how to name things from the start. See this bug for reference: https://bugs.webkit.org/show_bug.cgi?id=69451 Thoughts? -Darin On Thu, Oct 6, 2011 at 2:07 PM, Alexey Proskuryakov a...@webkit.org wrote: 06.10.2011, в 13:49, Scott Graham написал(а): The first revision of the spec (from the Scope section) is intended to handle: ... support for devices common to current gaming systems including gamepads, directional pads, joysticks, wheels, pedals, accelerometers. Why does the spec title and abstract talk about gamepads (joysticks) only? Perhaps it's my mistake that I didn't read the scope section, but with title and abstract being so specific, that seemed unnecessary. Skipping scope section, I went right to IDL. Why is the interface called Gamepad if it's not only about gamepads? - 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] DOMCrypt
For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Moving forward on that part first sounds reasonable. I've been asked about that specifically by some app developers that really aren't interested in the other parts of the larger proposal. On Wed, Jul 27, 2011 at 10:06 AM, Sam Weinig wei...@apple.com wrote: I think we should let the spec mature a bit before diving in. -Sam On Jul 26, 2011, at 10:53 PM, Adam Barth wrote: Hi webkit-dev, As some of you are probably aware, Mozilla is experimenting with exposing some basic cryptographic primitives to web applications: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest I wanted to get a sense from the WebKit community about how interested we are in implementing this feature. My sense is that this API is fairly early in it's lifecycle, so one perspective is that we should wait for Mozilla to experiment for a bit longer and revisit this question once the design is further along (e.g., submitted to the W3C standards process). Another perspective is that there are some simple parts of the API that we should implement now, and we can grow into the more involved parts of the API as they mature. For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOMCrypt
Yes, hashing blobs. Here's the last line of the relevant meeting notes... In the end, we all agreed that the main thing with the highest utility would be a native hashing implementation that could accept strings, bytes, or BLOBs. On Fri, Aug 5, 2011 at 12:32 PM, Adam Barth aba...@webkit.org wrote: On Fri, Aug 5, 2011 at 12:09 PM, Michael Nordman micha...@google.com wrote: For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Moving forward on that part first sounds reasonable. I've been asked about that specifically by some app developers that really aren't interested in the other parts of the larger proposal. Are they specifically interested in hashing blobs? David and I have been discussing what sort of types these functions should handle. Adam On Wed, Jul 27, 2011 at 10:06 AM, Sam Weinig wei...@apple.com wrote: I think we should let the spec mature a bit before diving in. -Sam On Jul 26, 2011, at 10:53 PM, Adam Barth wrote: Hi webkit-dev, As some of you are probably aware, Mozilla is experimenting with exposing some basic cryptographic primitives to web applications: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest I wanted to get a sense from the WebKit community about how interested we are in implementing this feature. My sense is that this API is fairly early in it's lifecycle, so one perspective is that we should wait for Mozilla to experiment for a bit longer and revisit this question once the design is further along (e.g., submitted to the W3C standards process). Another perspective is that there are some simple parts of the API that we should implement now, and we can grow into the more involved parts of the API as they mature. For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOMCrypt
I think bytes and blobs would be sufficient. +f...@google.com On Fri, Aug 5, 2011 at 12:58 PM, Adam Barth aba...@webkit.org wrote: Bytes and (likely) blobs are types we're planning to do in DOMCrypt. Hashing strings is slightly more delicate because you need to pick an encoding. Do you have a sense, if we did bytes and blobs, would that be enough, or are strings really important also? Thanks, Adam On Fri, Aug 5, 2011 at 12:43 PM, Michael Nordman micha...@google.com wrote: Yes, hashing blobs. Here's the last line of the relevant meeting notes... In the end, we all agreed that the main thing with the highest utility would be a native hashing implementation that could accept strings, bytes, or BLOBs. On Fri, Aug 5, 2011 at 12:32 PM, Adam Barth aba...@webkit.org wrote: On Fri, Aug 5, 2011 at 12:09 PM, Michael Nordman micha...@google.com wrote: For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Moving forward on that part first sounds reasonable. I've been asked about that specifically by some app developers that really aren't interested in the other parts of the larger proposal. Are they specifically interested in hashing blobs? David and I have been discussing what sort of types these functions should handle. Adam On Wed, Jul 27, 2011 at 10:06 AM, Sam Weinig wei...@apple.com wrote: I think we should let the spec mature a bit before diving in. -Sam On Jul 26, 2011, at 10:53 PM, Adam Barth wrote: Hi webkit-dev, As some of you are probably aware, Mozilla is experimenting with exposing some basic cryptographic primitives to web applications: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest I wanted to get a sense from the WebKit community about how interested we are in implementing this feature. My sense is that this API is fairly early in it's lifecycle, so one perspective is that we should wait for Mozilla to experiment for a bit longer and revisit this question once the design is further along (e.g., submitted to the W3C standards process). Another perspective is that there are some simple parts of the API that we should implement now, and we can grow into the more involved parts of the API as they mature. For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The http tests are very flaky
lighttpd+cgiphp is not super reliable... i think that accounts for some amount of chromium's http test flakiness on windows. On Fri, Jan 14, 2011 at 10:07 AM, Julie Parent jparent+web...@gmail.com wrote: For Chromium, the http tests aren't very flaky on Mac (I see only 5 flaky http tests). Windows, however, is another story. On Fri, Jan 14, 2011 at 8:54 AM, Ojan Vafai o...@chromium.org wrote: On Thu, Jan 13, 2011 at 11:10 PM, Eric Seidel e...@webkit.org wrote: Looking at the Chromium Flakiness dashboard (which has results going back for months!) we see that many of the same http tests are flaky for chromium too: http://test-results.appspot.com/dashboards/flakiness_dashboard.html I believe they use a different http server (lighttpd, but my information could be old?) and certainly a separate network stack. We use lighttpd only on Windows. It's been on our long-term TODO list to use apache on Windows again, but getting it to work on Vista/Win7 has proven tricky. 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XHR responseArrayBuffer attribute
Yes, if we go with telling xhr up front for the array buffer case, I guess an enum would be slightly better. On Fri, Sep 24, 2010 at 8:39 PM, Chris Rogers crog...@google.com wrote: If we added xhr.asArrayBuffer, what would happen if xhr.asBlob was also set? Don't we really want something like xhr.loadAsType with different enum values for text, blob, array buffer, etc.? On Fri, Sep 24, 2010 at 5:19 PM, Michael Nordman micha...@google.comwrote: With xhr.responseBlob we chose to have the caller decide up front and tell the xhr object how it would like the response by setting the xhr.asBlob attribute prior to calling send(). We could do the same with xhr.asArrayBuffer. On Fri, Sep 24, 2010 at 5:09 PM, Alexey Proskuryakov a...@webkit.orgwrote: 24.09.2010, в 16:37, Chris Rogers написал(а): I was interested to know if anybody was planning on implementing that attribute soon. If not, I would like to add this myself. The key problem to solve is how to not double the memory use of the XMLHttpRequest object, while not making responseText and responseXML slow. See also: https://bugs.webkit.org/show_bug.cgi?id=40954. Do we need both responseBody and responseArrayBuffer? - 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] XHR responseArrayBuffer attribute
Webkit's XHR currently does not keep two copies of the data that I can see. I think we should avoid that. On Mon, Sep 27, 2010 at 2:40 PM, Anne van Kesteren annevankeste...@gmail.com wrote: (I'm subscribed to webkit-dev with a different address.) On Mon, Sep 27, 2010 at 8:31 PM, Michael Nordman micha...@google.com wrote: Yes, if we go with telling xhr up front for the array buffer case, I guess an enum would be slightly better. I do not think this should be told up front. You already need to keep the octet buffer in memory for overrideMimeType to work the way it does. We designed responseBlob as an optimization so you would not have to deal with the other types. I do not think you can optimize the reverse with the design as it stands today. In any event, any discussion on changes to the specification really ought to happen on public-weba...@w3.org. Cheers, -- Anne van Kesteren http://annevankesteren.nl/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XHR responseArrayBuffer attribute
With xhr.responseBlob we chose to have the caller decide up front and tell the xhr object how it would like the response by setting the xhr.asBlob attribute prior to calling send(). We could do the same with xhr.asArrayBuffer. On Fri, Sep 24, 2010 at 5:09 PM, Alexey Proskuryakov a...@webkit.org wrote: 24.09.2010, в 16:37, Chris Rogers написал(а): I was interested to know if anybody was planning on implementing that attribute soon. If not, I would like to add this myself. The key problem to solve is how to not double the memory use of the XMLHttpRequest object, while not making responseText and responseXML slow. See also: https://bugs.webkit.org/show_bug.cgi?id=40954. Do we need both responseBody and responseArrayBuffer? - 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] Blob scheme implementation
On Wed, Sep 15, 2010 at 9:15 AM, Darin Fisher da...@chromium.org wrote: On Wed, Sep 15, 2010 at 8:58 AM, Alexey Proskuryakov a...@webkit.orgwrote: 14.09.2010, в 22:15, Darin Fisher написал(а): I think it makes sense to extend ResourceHandle.cpp to access the BlobRegistry singleton in order to support blob URLs. The problem I see with adding blob support to ResourceHandle is that it makes it too difficult to maintain. It used to be a platform abstraction, and it was hard enough to make sure it worked well across platforms. Adding a significant amount of cross-platform logic on top of that isn't going to make it easier - especially when it's done via subclassing. I don't understand why this seems so complicated. ResourceHandle.cpp contains some code that is shared by all WebKit ports that can access their network stack directly from the WebKit main thread. It already has some common code for handling certain error cases (invalid URL, bad port). This is the best point in the code to integrate blob URL support. Maybe subclassing ResourceHandle is not the best way to go about this. It seems fairly clean to me, but then, I'm not sure what the alternative proposals look like. An example that prompted me to look into this was http://trac.webkit.org/changeset/67503. Here, a static function that reported platform capabilities had to become virtual, so that it could take blob loading logic into account. There is nothing in common between are we running on a version of Mac OS X that supports this and are we loading a blob, and remembering this twist won't be easy. Perhaps the static function should remain but be renamed? That way it can remain the function that reports platform capabilities. However, as this patch demonstrates, from WebCore's point of view, this needs to be a property of ResourceHandle. Maybe it would help if we better formalized the abstraction to the network stack and let ResourceHandle grow to be a smart (contains cross-platform helper code) front-end to that. +1 Maybe it would help if we better formalized the abstraction to the network stack and let ResourceHandle grow to be a smart (contains cross-platform helper code) front-end to that. AppCache loading has been mentioned a couple times in this thread. Really, the points of integration between the loader and the appcache are mostly smoke and mirrors in chrome... loading out of an appcache actually happens via ResourceHandle in our port. Webcore's webarchive loading wouldn't work in a sandboxed renderer either. I'm working up to a similar 'where to put what code' conundrum around xhr.responseBlob. Ideally, I'd like ResourceHandle to produce the blob. ResourceHandle vs PlatformResourceHandle, maybe a class like the latter could have a 'capabilities' interface that allowed common code to query things like 'CanProvideResponseBlobs' and if not provides that capability in common code. Similarly a 'CanHandleBlobScheme' capability query could provide a fork in the road for loading blob urls (so the common code impl would poke at the BlobRegistry singleton). Subclassing ResourceHandle for blob url loading is probably not the most elegant thing, but given the current state of the code base, it's not a bad option. This schism around ResourceHandle in particular is a recurring theme. The recurring answer do it in the loader just doesn't work so well for us. -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] How to handle a new protocol for Blob.url support?
Does webcore have a 'protocol handler' abstraction that can be leveraged to add support for a new protocol scheme? I don't think it does, but an abstraction like that may help with this. On Wed, Jun 2, 2010 at 6:19 PM, Jian Li jia...@chromium.org wrote: This will probably work for most of the platforms, except the one that uses multi-process architecture. How do we handle the case that a page is trying to access a blob URL that is created in another process (assume the accessing page is in the same security domain)? I think for the platform, like Chromium, we can choose to delegate to the host to do the right job, while all other platforms will share the same handling logic defined at a higher level. In addition, we might need to hook up additional logic if we want to support using it in the shared worker process. On Wed, Jun 2, 2010 at 6:08 PM, Darin Adler da...@apple.com wrote: On Jun 1, 2010, at 5:14 PM, Jian Li wrote: I am working on Blob.url support as defined in the latest version of File API (http://dev.w3.org/2006/webapi/FileAPI/). The Blob.url will return a URL that can be used to refer to the blob object in a resource request, like blobdata:f81d4fae-7dec-11d0-a765-00a0c91e6bf6. The blob object can represent a whole file, a partial file (created by Blob.slice), or a byte array (created by BlobBuilder defined in the FileWriter spec). What is the right place I can hook up with in order to interpret and process the blobdata request? Should it be in the WebKit library layer that will be implemented by individual platform or in the higher layer like what application cache does the work? Definitely a higher level. We don’t want to have to reimplement a feature like this for each platform. -- 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] MD5 in WebCore
In webcore, should we use the same impl on all platforms rather than use
cryptdll on windows and md5.cc elsewhere?
For chrome, I don't think we can have a dependency between
WebKit/WebKit/chromium and /src/base/, and 'base' depending on 'webkit' also
doesn't work. How can we avoid replicating the code? I guess having
webcore's MD5 be platform specific could help us along those lines?
On Tue, Apr 20, 2010 at 4:12 AM, Maciej Stachowiak m...@apple.com wrote:
On Apr 20, 2010, at 3:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:
I'm implementing new protocol of WebSocket (
http://www.whatwg.org/specs/web-socket-protocol/ ).
Since it now requires MD5 in handshake, I wonder how I could add MD5 in
WebCore. For now, there is no MD5 in WebCore. It is in
WebKitTools/DumpRenderTree to get message digest of image file.
I'm thinking to add new header file as WebCore/platform/MD5.h, which
provides the following functions.
struct MD5_CTX;
void MD5_Init(MD5_CTX*);
void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
void MD5_Final(unsigned char hash[16], MD5_CTX*);
In Windows platform, it is implemented using Cryptdll.dll. Is it ok to
copy WebKitTools/DumpRenderTree/win/MD5.cpp to WebCore/platform/win/MD5.cpp,
or move?
In Mac platform, it is provided by CommonCrypto/CommonDigest.h with
#define COMMON_DIGEST_FOR_OPENSSL ?
In Chromium, there is chrome/src/base/md5.{h,cc}. Should I copy this in
WebCore/platform/chromium, or add dependency to base from WebCore?
How about other ports? is it ok to link openssl or some other library?
(or use implementation used in chromium?)
I'm also wonder I need to put these functions in namespace WebCore.
If you put this code in WebCore, it should go in the WebCore namespace. I
think it would also be a good idea to turn the API into something more
WebCore-ish, something like:
namespace WebCore {
class MD5 {
MD5(); // what was MD5_Init
addBytes(uint8_t* input, size_t length); // what was MD5_Update ;
or maybe this should take a Vectoruint8_t?
Vectoruint8_t, 16 checksum(); // what was MD5_Final
};
}
(The key point being to match the coding style guidelines for names, but it
also seems better to use a class here instead of a struct and functions that
take a pointer to it.)
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] WTF::callOnMainThread() and re-entrancy
On Tue, Mar 9, 2010 at 11:13 AM, Alexey Proskuryakov a...@webkit.org wrote: On 09.03.2010, at 9:45, Drew Wilson wrote: Yeah, it's a race condition - it seems to all depend on whether the worker resource gets loaded before the postMessage loop starts. Failure rate is around 30-50% on my machine. It would help to have a more detailed description of the problem. I've been following the discussion in bugs and in this thread, but I'm still unsure about some aspects of it. Seems that there are two issues at hand: 1) We feel the need to change how Document::postTask() behaves, because otherwise, the patch for https://bugs.webkit.org/show_bug.cgi?id=34726 doesn't work. We feel the need because it makes little sense for it to have drastically different behavior depending on what thread it's called from. It feels like a good change to make indeed, but I'm surprised that it apparently went through review unmentioned and unquestioned. The questions to ask are why exactly it was needed, and whether there are other ways to fix bug 34726. This was discussed somewhat off list between dumi, dimich, and myself (and whomever else dumi traded notes with). We were very surprised that tasks scheduled via postTask() were not executed in the same order as being scheduled. This change to postTask() was a shot at remedying that... but low and behold, something was apparently depending on the out of order execution? 2) if we make that change, the worker-cloneport.html test starts to fail. I didn't attempt to debug this myself, and I don't quite understand the problem description. I see only one postMessage loop in the test, and it's in worker code. How can it be executed before the worker resource gets loaded? It looks like events have priority in Cocoa, and I'm guessing that performSelectorOnMainThread() creates events with a higher priority than those generated by URLConnection, which can lead to starvation. I'm not certain what the right fix is, other than to maybe use a different method of dispatching events other than performSelectorOnMainThread that lets us set a lower priority? These main thread calls do not use events for processing. CF/NSRunLoop has a concept of run loop sources, which can generate events or perform other actions, see http://developer.apple.com/mac/library/documentation/CoreFoundation/Reference/CFRunLoopRef/Reference/reference.html and http://developer.apple.com/Mac/library/documentation/CoreFoundation/Reference/CFRunLoopSourceRef/Reference/reference.html . - 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] Question on FormData interface and implementation
option 3: We could name any new classes backing the new scriptable object as DOMFormData (similar in sprirt to DOMWindow), and leave the existing FormData classes as they are. On Thu, Feb 25, 2010 at 3:31 PM, Jian Li jia...@chromium.org wrote: Hi, I am looking into the work to support FormData interface as defined in XMLHttpRequest Level 2 ( http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#formdata). To support the new FormData interface, we need to add the FormData object that collides with the name that has already existed. Currently we already have FormData and FormDataElement that encapsulate the formalized data to send out. How are we going to resolve the naming issue? Approach 1: we can try to merge the current version of FormData with the new functionalities in the to-be-added FormData. This means that the new version will handle both raw key-value-pair FormData and formalized FormData. It seems to be a little bit messy, IMHO. Approach 2: we can rename the current version of FormData to something like FormalizedFormData or FormSendingData that keeps all the current logic to represent the formalized data to send out. We then use FormData for the new FormData interface, that represent the raw key-value-pair list, just like FormDataList. Indeed we will merge FormDataList into this new version of FormData. How do you guys think? Thanks, Jian ___ 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] SharedScript: next steps and result of offline discussion.
On Mon, Dec 14, 2009 at 9:16 PM, Darin Fisher da...@chromium.org wrote: I think that use case has been de-emphasized. However, if we wanted to support it, we'd probably have to say that removeChild of an IFRAME element doesn't cause the unload event to be dispatched. (I'm a bit concerned that that may cause incompatibilities with existing pages.) Then, you'd have to store a reference to the IFRAME element in a global variable, so that you could find it again when the next document is loaded. I hope this use-case can be accommodated, I think this is ultimately the more generally applicable use-case. Btw, concern for incompatibilities with existing pages was one reason we came up with a new construct for this capability (instead of overloading iframe or script). How does 'reparentling' work in the absence of the use-case i mentioned? When the current parent removes the iframe from its DOM, does unload not get fired, do pending xhr's, and do timers continue run such that they survive after being added to a new parent's DOM how's that work in the magic iframe scheme? -Darin On Mon, Dec 14, 2009 at 2:50 PM, Michael Nordman micha...@google.comwrote: How does reparenting across in-place frame navigations work in this scheme? Is a de-parented iframe guaranteed to linger long enough for the new page to get it by name and re-parent it if desired? On Thu, Dec 3, 2009 at 7:01 PM, Dmitry Titov dim...@chromium.org wrote: Hi WebKit, The recent discussion indicated there is a feeling that SharedScript functionality can be achieved by other means that do not require adding new big APIs: changing iframe a bit (so it's internals survive reparenting into another document) and adding single getWindowByName() API. Ian Hickson proposed this idea noting that nothing in the spec prevents iframe from staying alive over the reparenting. Some folks from Google met with folks from Apple to discuss and it appears there is a consensus that we shall remove initial code for SharedScript and instead implement changes for iframe and getWindowByFrame(). This will not cause new API and hopefully won't cause compatibility issues since the only scenario that will behave differently is reparenting of the iframe between documents that is hopefully a rare thing. Perhaps more discussion will be needed to nail details on those. Separately (or related?), we discussed SharedWorkers and the way XHR works in them. It seems a good idea to investigate a shadow document' solution (as Chrome does for worker processes) when a dummy document is created and used to load resources on behalf of the worker. Also we'll try to fix couple of bugs that prevent Workers to be reliable enough. Thanks a lot to all who chimed in and helped to arrive to a good solution to the same issues that SharedScript was trying to solve! :-) Dmitry Titov ___ 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] SharedScript: next steps and result of offline discussion.
Saving a subsite of live script and DOM objects across a full page load does not seem useful to me Lots of sites use actual frame navigations to navigate. On Tue, Dec 15, 2009 at 12:06 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 15, 2009, at 11:09 AM, Michael Nordman wrote: On Mon, Dec 14, 2009 at 9:16 PM, Darin Fisher da...@chromium.org wrote: I think that use case has been de-emphasized. However, if we wanted to support it, we'd probably have to say that removeChild of an IFRAME element doesn't cause the unload event to be dispatched. (I'm a bit concerned that that may cause incompatibilities with existing pages.) Then, you'd have to store a reference to the IFRAME element in a global variable, so that you could find it again when the next document is loaded. I hope this use-case can be accommodated, I think this is ultimately the more generally applicable use-case. Btw, concern for incompatibilities with existing pages was one reason we came up with a new construct for this capability (instead of overloading iframe or script). If you want to minimize new work on a page transition, then you should use history.pushState and alter the content in place. Saving a subsite of live script and DOM objects across a full page load does not seem useful to me, since likely removing the full page load will be a bigger improvement to load time and responsiveness. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedScript: next steps and result of offline discussion.
How does reparenting across in-place frame navigations work in this scheme? Is a de-parented iframe guaranteed to linger long enough for the new page to get it by name and re-parent it if desired? On Thu, Dec 3, 2009 at 7:01 PM, Dmitry Titov dim...@chromium.org wrote: Hi WebKit, The recent discussion indicated there is a feeling that SharedScript functionality can be achieved by other means that do not require adding new big APIs: changing iframe a bit (so it's internals survive reparenting into another document) and adding single getWindowByName() API. Ian Hickson proposed this idea noting that nothing in the spec prevents iframe from staying alive over the reparenting. Some folks from Google met with folks from Apple to discuss and it appears there is a consensus that we shall remove initial code for SharedScript and instead implement changes for iframe and getWindowByFrame(). This will not cause new API and hopefully won't cause compatibility issues since the only scenario that will behave differently is reparenting of the iframe between documents that is hopefully a rare thing. Perhaps more discussion will be needed to nail details on those. Separately (or related?), we discussed SharedWorkers and the way XHR works in them. It seems a good idea to investigate a shadow document' solution (as Chrome does for worker processes) when a dummy document is created and used to load resources on behalf of the worker. Also we'll try to fix couple of bugs that prevent Workers to be reliable enough. Thanks a lot to all who chimed in and helped to arrive to a good solution to the same issues that SharedScript was trying to solve! :-) Dmitry Titov ___ 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] Database in Worker context
not clear to me what benefit could be had by effectively splitting a class in two Perhaps more easily worked on by multiple hands in parallel with fewer conflicts. Various bits of database stuff are better encapsulated in database specific classes (so maybe easier to learn how the system works when code snorkling). Either way would work of course, the direction eric's heading seems like a clean way to factor things. On Thu, Dec 10, 2009 at 11:09 AM, Eric Uhrhane er...@chromium.org wrote: On Wed, Dec 9, 2009 at 6:55 PM, Dmitry Titov dim...@chromium.org wrote: Thanks for the link to the prototype code! If I understand it right and the DatabaseManager can not have any other relationship with ScriptExecutionContext but 1-1 and their lifetime is the same then it's not clear to me what benefit could be had by effectively splitting a class in two. The fact that DatabaseManager is RefCounted also hints that some other object could take ownership of it as well outside of lifetime of ScriptExecutionContext, but is this true? That's there because the DatabaseThread [and therefore the Database] can stick around for a bit after the ScriptExecutionContext is deleted if I make it non-refcounted. If I move the DatabaseManager parts into the ScriptExecutionContext, then I have to make sure that the SEC sticks around until after the Database and DatabaseThread have gone away. I can do that--the benefit I thought I was getting wasn't one of object lifetime. I just thought the classes were cleaner this way. But if you really think it's better to have it all in together, I can certainly move it. ScriptExecutionContext collects functionality common for Workers and Documents, and as such is a home for a few 'groups' of methods, like a few methods to deal with MessagePorts. MessagePort, in turn, has a raw pointer back to ScriptExecutionContext - so it's clear that MessagePorts do not outlive the SEC. Same pattern could be used for ScriptExecutionContext/Database, for consistency. It also simplifies design a bit - no need for a special refcounted manager class, and things like callOnJavaScriptThread could be replaced by SEC::postTask() which is already implemented. The point of CallOnJavascriptThread is that the JS thread is the Main Thread in the Document context, but [in Chromium's implementation] NOT in the Worker context. I needed a virtual method to distinguish between the two cases, since the Database code previously treated isMainThread as synonymous with isJavascriptThread. But of course that virtual method can be moved to Document and SEC instead of DDM and WDM. On Wed, Dec 9, 2009 at 5:21 PM, Eric Uhrhane er...@chromium.org wrote: On Wed, Dec 9, 2009 at 4:11 PM, Dmitry Titov dim...@chromium.org wrote: On Wed, Dec 9, 2009 at 12:58 PM, Eric Uhrhane er...@chromium.org wrote: I've pulled the database-related members out of Document and made a new class for them, DatabaseManager. An instance of that is owned by each ScriptExecutionContext. There are two flavors, DocumentDatabaseManager and WorkerDatabaseManager. They're not very different, but in a few cases it was necessary to distinguish between them I don't see your code, just generic thought: If those classes are small, then perhaps ScriptExecutionContext could absorb a couple of methods to deal with that? Some of them could be virtual and implemented differently on Document and WorkerContext. Dmitry You don't see the code because I sent this as an early warning--there's nothing checked in yet. The classes aren't huge, and in fact most of the code was in Document before, but given that it's all to do with a separable concept [the Database], I thought it nicer to pull it out. Let's see...DatabaseManger.cpp is 172 lines [including copyright headers, etc.] and the header is 107. Seems like a lot to sprinkle through ScriptExecutionContext, Database, and WorkerContext. You can take a look at my current code [where I'm backing it up--this won't actually be sent for review from this repository] at http://codereview.chromium.org/401016/show [mostly storage + v8 bindings] and http://codereview.chromium.org/464018/show [mostly Chrome browser process stuff] and see what you think. Thanks, Eric ___ 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] Proposing style guide change regarding braces on conditional arms
what peter pitched and what mjs pitched are one and the same i think * When all arms of a conditional or loop are one physical line, do not use braces. If any arms are more than one physical line (even if they are one logical line), use braces on all arms. One possible conservative modification to the rule is that if you have a multi-block if ... else if ... else chain, then if even one body has braces, all should. I think that would tend to reduce rather than increase visual noise, as all the else keywords would line up where right now they look ragged. +1 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] localStorage quota limit
Could WebKit configure the localstorage database(s) to use UTF8 text encoding for string values? On Sun, Nov 29, 2009 at 8:38 AM, William Edney bed...@technicalpursuit.comwrote: All - I've been discussing the localStorage quota limit over on this bug with Jeremy Orlow: https://bugs.webkit.org/show_bug.cgi?id=31791 To recap from the discussions on that bug: Jeremy has implemented the localStorage quota on the latest Webkit builds. This caused my usage of localStorage to fail, because as a JS programmer, I assumed that 5MB meant '5 million characters' of storage. This assumption holds true on Firefox 3.5.X+ and IE8, but fails on Webkit since it stores things into localStorage as UTF-16. One option we discussed on that bug was getting the spec folks to alter the spec in one of three ways: - specify the quota in terms of 'characters' (or Strings, or whatever) thereby abstracting away the encoding problem entirely. - specify UTF-8 so that 'MB = characters' - specify a JS API such that the encoding could be specified. Jeremy wasn't too taken with any of these proposals, and in any case, they probably need to be taken up on the W3 group defining this stuff, not here. In any case, as Jeremy states in Comment #5 of the bug report, the spec's mentioning of 5mb is really just an example. And when I filed this bug on Mozilla's Bugzilla tracker: https://bugzilla.mozilla.org/show_bug.cgi?id=461684 another comment there points out the same thing. (Note that this bug was originally filed to see if the Mozilla guys would raise their quota to 10MB to match IE8 and, since they don't use double-byte encoding, I was really asking for '10 million characters' there :-)). Given that, an increase from 5MB to 10MB would 'solve my immediate problem'. And, without going back to the spec folks, I'm not sure that much more can be done here. Jeremy wanted me to post to get the discussion started (and hopefully attain some consensus :-) ), so let's discuss :-). Thanks in advance! Cheers, - Bill ___ 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] localStorage quota limit
Arguably, seems like a bug that invalid string values are let thru the door to start with? Since users can't effectively store invalid UTF16 character sequences in FF or IE, is there really any downside to using UTF8 text encoding in WebKit? @Jeremy, this isn't a matter of letting users choose the text encoding, this is entirely an implementation detail of WebStorage. Downsides * The code change to get UTF8 by default in new databases, tiny. * Migrating pre-existing databases to the new encoding. Somewhat of a hassle. But maybe doesn't need to be done, pre-existing files could continue to use UTF16, while newly created dbs could use UTF8 (the text encoding is chosen at database creation time and stuck that way forever thereafter). * Its possible that some app is already depending on the ability to store invalid character sequences (on the iPhone say), and this would be a breaking change for that app. The preload everything characteristic is a separate issue altogether. On Wed, Dec 2, 2009 at 11:15 AM, Jeremy Orlow jor...@chromium.org wrote: IE chokes (invalid procedure call or argument) and Firefox mangles the data for LocalStorage (but works fine for SessionStorage). On Wed, Dec 2, 2009 at 10:54 AM, Darin Adler da...@apple.com wrote: On Dec 2, 2009, at 10:48 AM, Jeremy Orlow wrote: How can you construct invalid UTF-16 sequences? http://unicode.org/faq/utf_bom.html#utf16-7 -- 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] GlobalScript in WebKit
Just to provide some history... An intrinsic aspect of the SharedScript proposal is that scripting across the page / sharedScript boundary should be very fast. When coming up with the original proposal, we were careful to not require singleton semantics that would work against that goal (by requiring ipc proxy'ing and thread synchronization). A common context for all instances of a page was intentionally not a goal since to make that gaurantee would be very much at odds with the performance goal. We tried to strike that balance between the scope of sharing and the promise of being performant by saying all pages within a unit of related browsing contexts are guaranteed to shared the same SharedContexts. In our proposal, the scope of shared is permitted to be wider, but is not required to be wider. A secondary concern is co-locating top-level pages to widen the scope of sharing beyond just the unit of related browsing contexts. We've hand waved at hints that could help the browser accomplish that. On Tue, Dec 1, 2009 at 12:20 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 1 Dec 2009, Michael Davidson wrote: On Tue, Dec 1, 2009 at 11:51 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 1 Dec 2009, Michael Davidson wrote: No, we definitely want to share network connections. We'd like users to be able to have an arbitrary number of Gmail windows open without running into the browser connection limit. SharedScript doesn't give you that. Only a singleton mechanism can give you that. Assuming that the same-process hinting works, it will give us that. The process hinting is not a guarantee. It is trivial to come up with situations where different documents from the same origin are required to end up in different processes. Furthermore, as a user, I would personally much rather every GMail instance I open end up in a different process, for the same reason that I'd like GMail and Google Calendar in different instances, and Google Calendar and Google Search in different processes, and Search and pages I get to from Search in different processes. At the very least, it will vastly improve the situation we have today. Either you definitely want to share network connections, in which case it doesn't give you what you want, or you don't need to share network connections, in which case it seems no better than an iframe. The iGoogle gadget that you mention later would not use SharedScript, FWIW. Sure, but if it opens a true GMail window, that GMail window would have to end up in the same process as the parent (so that the opener can be accessed), which means it wouldn't be the same process as other GMail tabs. It doesn't have to be an iGoogle gadget; any page that window.open()s GMail would be in this situation as far as I can tell. I agree that anything that lives in an iframe is going to cause problems for SharedScript, but Gmail (like many webapps where having the URL exposed to the user is very important) doesn't allow itself to be in an iframe. It prevents it using script, which is too late since the process selection happens long before the script runs. It seems that you could just create an iframe instead of the SharedScript, and pass it around onunload. Can an iframe live independently of its creating document? Per spec, yes, so long as it is owned by a living document it'll keep existing. It should even work in browsers so long as you actually keep the iframe grafted to an existing Window's Document -- hence the pass it around onunload to keep it alive. The goal is not to mislead people into thinking that SharedScript is bulletproof sharing, which is why the spec says that sharing might fail. Yes, but people will think that's what it does, regardless of what it does, because in most testing that's what it will do. It's like the localStorage debacle -- we have to offer consistency guarantees because people will assume them regardless of what the spec says. Anyway, I'm not trying to discourage experimentation here; I just wanted to make it clear that SharedScript doesn't solve the shared networking problem, because it can never be guarenteed to be a singleton -- indeed, from the user's perspective, it would be undesireable for it to be possible to make the browser always put all tabs from one origin into the same process even if it was possible. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GlobalScript in WebKit
http://alex.dojotoolkit.org/2007/12/the-w3c-cannot-save-us/ What a great rant :) I'm also reminded of this quote... The reasonable man adapts himself to the world. The unreasonable man persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man. -George Bernard Shawhttp://en.wikipedia.org/wiki/George_Bernard_Shaw The Chrome team has come around to putting this particular feature into Chrome as an experiment. It's not clear that can be pulled off without actually putting some bits into WebKit, and I think we're of the opinion that the cleanest implementation is to have the code reside entirely in WebKit. (Personally, I think to do otherwise puts us into the realm of hackery to pull off the experiment.) Sam said It adds extra complexity to WebKit. We can and should keep a careful eye to minimize that. On Mon, Nov 30, 2009 at 9:55 AM, Dimitri Glazkov dglaz...@chromium.orgwrote: 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. This doesn't mean we shouldn't discuss technical merits of the proposed solution, including more efficient ways of accomplishing the same thing. :DG On Thu, Nov 26, 2009 at 9:44 AM, Dmitry Titov dim...@chromium.org wrote: What I meant was it would be nice, for the sake of discussion, to share the experience of real life applications that used SharedWorkers or inter-window communications for sharing of significant portions of code and data. Google apps may be a partial example but it is a real life example of concrete issues with proposed solution that sounds pretty generic and useful for other web apps. It is only prudent to take their feedback rather then replace it with our own theories about future of the web. No doubt this is a new mechanism and it's good to question it, since it has costs even as experimental API. Gut feelings vary, some app devs say they need it to solve real issues, we dont hear from other app devs who were facing similar issues and solved it differently. Seems there is no strong argument to kill it nor bless it. Why don't make it experimental and see? If it was possible to implement it in extension or plugin, we would run it as another Gears-like experiment, but it can not be done in a plugin... I believe there could be good arguments that simply didn't surface yet, and hope to hear them. Dmitry. On Wed, Nov 25, 2009 at 10:16 PM, Peter Kasting pkast...@google.com wrote: On Wed, Nov 25, 2009 at 9:41 PM, Dmitry Titov dim...@chromium.org wrote: BTW, could you tell what's the 'course' that would be reverted? Meaning, before we decide that SharedWorkers and inter-window communication are insufficient, and a further proposal should be entertained by the standards community. 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 ___ 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
window.applicationCache does something different when the runtime switch is disabled which definitely breaks feature detection. It returns a non-null, but non-functioning object. At some point I had changed it to return 'null' when disabled, but later reverted that change and went back to the non-null but not-working state of affairs after discussing things with ap. On Mon, Oct 5, 2009 at 7:50 PM, Drew Wilson atwil...@google.com wrote: Ooops, meant to reply to all. On Mon, Oct 5, 2009 at 7:49 PM, Drew Wilson atwil...@google.com wrote: On Mon, Oct 5, 2009 at 6:40 PM, Sam Weinig sam.wei...@gmail.com wrote: That is not true, they are also available in nightly builds at http://nightly.webkit.org/. I'm not sure what you mean, exactly - the nightly webkit builds all have SharedWorkers turned on, with no way to turn them off short of editing the source code and recompiling (since the only existing implementation of SharedWorkerRepository.isAvailable() returns true). I suspect I'm missing something obvious, though - can you elaborate? My expectation was that only when I write the Chromium implementation of SharedWorkerRepository will isAvailable() ever return false - so this only affects Chromium deployments. 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. Why doesn't it affect feature detection? Someone can do if localStorage in window, yet have their code fail when window.localStorage is null? -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
Re: [webkit-dev] Loading from shared workers (shadow documents?)
On Fri, Aug 7, 2009 at 11:06 AM, Drew Wilson atwil...@google.com wrote: Hi all, I'm about to work on adding network access support to shared workers. To refresh your memory, shared workers can outlive any specific document object - they exit when the last referring document exits. Current dedicated workers just proxy all network operations over to their associated Document object. If the Document is closed prematurely, then the network operation is aborted and an error is returned to the worker, which is fine because the Worker is exiting anyway. For shared workers we can't just proxy network operations over to an arbitrary parent document, because the user may choose to close that document in mid-load yielding an inappropriate error response to the user. We have a few options: 1) If a document closes mid-load, just return an error to the worker. So treat this case like Just Another Network Hiccup. 2) If a document closes mid-load, just retry the network access on another parent document. I'm not certain that this is acceptable from a spec-compliance standpoint (the server might end up seeing multiple network requests even though from the client stand point only one was issued). 3) Don't let documents fully go away while there's outstanding worker network access. For a long-lived hanging get, this seems like it might keep a document around (in hidden state) for a long time, and I'm not sure what the ramifications are of that. Also, there's the issue of how to deal with things like HTTP auth from hidden documents (although HTTP auth is problematic for shared workers in general as it's kind of arbitrary which window the auth UI appears under). 4) Create a new shadow document for the worker that it uses to satisfy all of its loading requests. This is what Chromium does for all its worker network access currently. This is the most robust solution, although I'm still not certain how HTTP auth would be handled in this case). #4 seems like the most sensible option long term. * Solves the bug around spurious failures when the parent goes away at just the wrong time. * Avoids some appcache related complications. A shared worker can be associated with an appcache that is all its own. It may be that none of the parent documents are associated with the same appcache (or any appcache). That situation seems like a recipe for awkward special cases in the loader to delegate to the 'right' appcachehost when its processing a request on behalf of a shared worker. Where to surface UI related to a shared worker's request is a good question. Maybe a shared workers requests shouldn't present UI for HTTPauth or SSL related prompts, anything that would require user intervention could just fail w/o leaving any traces (we'd have to be careful to distinguish these kind of failures from explicit user cancels when it came to the validity state associated with the SSL cert). I'm leaning towards #1 in the short-term, but I'd like to get feedback about what our long-term approach should be. -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] Calling All Reviewers
On Fri, Aug 7, 2009 at 3:37 PM, Joe Mason joe.ma...@torchmobile.com wrote: Adam Treat wrote: On Friday 07 August 2009 05:51:57 pm Eric Seidel wrote: We also definitely need to fix our tools to make it impossible to post a patch w/o a ChangeLog, and impossible to post a patch that doesn't pass check-webkit-style. This is a bad idea. check-webkit-style still has false positives and is very new. It has been designed to never be free of false positives in fact. Not to mention there will always be places where human judgement overrides the guidelines. Also, sometimes a patch is being posted not to be submitted, but to share code to get early feedback on something. Requiring no style lint errors for that use case seems overly restrictive. Joe ___ 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
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
Re: [webkit-dev] Reporting exceptions from worker context to users
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
Re: [webkit-dev] Reporting exceptions from worker context to users
Nor do I think that we should block development on arbitrary features like nested workers because we think we need better tools. A better solution would be to roll out a just barely good enough solution, get developer feedback on real use cases, and improve the tools over time to reflect that feedback, just as we do for every other feature in WebKit. absolutely... features come first ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
Having a dedicated shadow frame would be much simpler. Yup. I think this is required ultimately for appcache integration too. A shared worker is a distinct appcache host. Dedicated workers can get away with piggy backing of their owning document since they just use the same appcache as the page, but not shared workers. ___ 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, Jun 17, 2009 at 3:43 PM, Drew Wilson atwil...@google.com wrote: Following up again on this - now that my cross-thread MessagePort patch is getting close to landing, I am moving forward on the SharedWorker design described earlier in this thread. I think there is still little clarity around the appcache behavior (dimich: are you bring over your shadow frame concept to webkit?). I think we're making decent progress, but integration with workers is a ways off yet. First things first for me, get things working w/o workers. I'm wondering about bringing the 'shadow frame' technique to webcore too? It doesn't seem like it should block the rest of SharedWorker development while we work out the details - I will not expose the appcache APIs for SharedWorkers until we have consensus about how they should work. Sounds good. You should plow ahead without concern for appcache integration. I'll back fill later. We'll have similar backfilling to do with the Database too. Let me know if you have any concerns with my approach. I'll add an ENABLE_SHARED_WORKERS flag to control access to these APIs while development proceeds. -atw On Tue, Jun 2, 2009 at 11:43 AM, Michael Nordman micha...@google.comwrote: As for our implementation - I don't know how appcache is integrated with the loader code. We're still working out the details sans workers. But if it's a requirement to be able to a have an distinct appache host per shared worker, then so be it. If not, we either need to add this support, or delay exposing appcache APIs to SharedWorkers until we add the ability to load data from worker context without going through a document object (probably required for persistent workers). I'm for deferring appcache + worker integration until we have appcach - worker integration in place (including in place for chrome). Exposing the scriptable APIs to workers don't necessarily have to go in lock step with and appcache selection and resource loading on behalf of workers. There may be some overlap with work being done to support resource loading for dedicated workers in chrome. In chrome resource loads don't go thru the renderer process at all (so no Document/Frame instances). I think Dmitry was talking about introducing a FakeFrame (maybe not the best name) for this purpose. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
When a document calls a SharedWorker constructor, the worker script is loaded from the document's appcache (because all subresource loading goes through appcache, of course). If I understand correctly, that is not what the spec currently says. Dedicated workers load as you describe, but not shared workers. The algorithm to determine what resource to load for a shared worker is the same as the algorithm used to determine what resource to load for a window.open(urlToPageWithoutAManifestAttributre) call. Personally, I think we should defer adding support for the appcache scriptable API to workers for the time being. But do support the resource loading / cache selection as currently specified. This would allow shared workers can be versioned independently (despite not having a good reload worker after an update story). These are shared workers. That implies a degree of separation from the pages that are sharing them. But how is it a problem if we require SharedWorkers to implement a stable messaging API? There are other interfaces to consider. The client-server messaging interface used by the worker to talk to the mother ship. And more significantly, the localstorage schema used by the worker. Consider a newer version of a shared worker alters a local database schema. If an older version of the worker is pinned in some other appcache, that schema change is likely incompatible with the that older worker. 2009/6/1 Alexey Proskuryakov a...@webkit.org: 02.06.2009, в 1:29, Michael Nordman написал(а): What is the use case for this? It doesn't seem useful to me - to invoke update explicitly, one normally needs to have UI anyway, at which point it's much easier to call update() directly from a page. The use case are workers that can be considered faceless applications. They are versioned independently of user interfaces that make use of them thru a stable message based API. Is it really possible for a SharedWorker to be versioned independently from UI? When a document calls a SharedWorker constructor, the worker script is loaded from the document's appcache (because all subresource loading goes through appcache, of course). So, its source always matches the UI version. Even if there is a newer version of appcache already loaded, the document's one will be used for loading subresources. When a worker's script is referenced from several appcaches, this becomes somewhat trickier. As Andrew correctly mentioned, the version used will depend on which application was the first to construct the SharedWorker. But how is it a problem if we require SharedWorkers to implement a stable messaging API? Given that SharedWorkers are versioned together with UI, and that loading a new main resource in UI always invokes update process, I'm not sure if there are any use cases that require workers to call update() on their own. This is quite similar to how faceless helpers in large native application suites work - I don't think that they ever check for updates, it's only done at application startup. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
2009/6/2 Alexey Proskuryakov a...@webkit.org: From Andrew's design document, I don't see how my description was inaccurate: --- Currently, all worker XHR requests are proxied to the parent page and executed on the main thread. This approach currently works for dedicated workers because there is a 1:1 mapping between dedicated workers and active pages, and the worker is shutdown when the page closes. For SharedWorkers (and for dedicated workers once we introduce nested workers) this is no longer the case - the worker can outlive the parent page. To address this, we will use the DocumentSet for the worker. Worker XHR requests will still be proxied to the main thread. This task will request the DocumentSet from the repository, and select a document from that set to use to satisfy the request. If the DocumentSet is empty, then it means that the worker is shutting down, so the XHR should return a failure response. --- From my reading of this, it appears that shared workers will use FrameLoader of the opener page, or some other page in the DocumentSet, and won't get their own loaders (that would be a feature of persistent workers, which we aren't even discussing yet). This speaks specifically about XHR, but I assumed that the same holds true for other network requests. That would be a design flaw... not a feature. All of this stuff about the DocumentSet associated with a shared worker is a hack to work around the problem of how to load resource without a frame in webkit. Per the spec, shared workers are a distinct browsing context. In appcache terms, they have a distinct appcache host. We have to come up with a design that accomplishes that. - WBR, Alexey Proskuryakov 02.06.2009, в 21:18, Michael Nordman написал(а): When a document calls a SharedWorker constructor, the worker script is loaded from the document's appcache (because all subresource loading goes through appcache, of course). If I understand correctly, that is not what the spec currently says. Dedicated workers load as you describe, but not shared workers. The algorithm to determine what resource to load for a shared worker is the same as the algorithm used to determine what resource to load for a window.open(urlToPageWithoutAManifestAttributre) call. Personally, I think we should defer adding support for the appcache scriptable API to workers for the time being. But do support the resource loading / cache selection as currently specified. This would allow shared workers can be versioned independently (despite not having a good reload worker after an update story). These are shared workers. That implies a degree of separation from the pages that are sharing them. ___ 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 most appropriate app cache should be used A little off topic... the spec says that in regard to appcache selection in general, its not specific to workers. That squishiness should probably be better defined at some point. 2009/6/2 Drew Wilson atwil...@google.com: Basically, the spec says the most appropriate app cache should be used (which apparently we're free to interpret however we like), and that the SharedWorker should have the ability to update its current app cache. I think that the spec is fine. As for our implementation - I don't know how appcache is integrated with the loader code. Can I proxy a load to a given document, but still specify which version of the app cache I want to use? If so, then we don't need to change the design. If not, we either need to add this support, or delay exposing appcache APIs to SharedWorkers until we add the ability to load data from worker context without going through a document object (probably required for persistent workers). -atw 2009/6/2 Alexey Proskuryakov a...@webkit.org 02.06.2009, в 21:59, Michael Nordman написал(а): Per the spec, shared workers are a distinct browsing context. In appcache terms, they have a distinct appcache host. We have to come up with a design that accomplishes that. OK, I was getting a feeling that we talked about different things. Andrew, do you agree that a different design is needed, or is this something we should push into the spec instead? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
How workers and appcaches interact has been discussed on the WHATWG list. Ian's Worker feedback message on 3/27/09 tried to tie things up for the time being. I think where he left things was a reasonable stepping stone, although the answers to the questions being asked here about updates were not entirely resolved. What is the use case for this? It doesn't seem useful to me - to invoke update explicitly, one normally needs to have UI anyway, at which point it's much easier to call update() directly from a page. The use case are workers that can be considered faceless applications. They are versioned independently of user interfaces that make use of them thru a stable message based API. A tangentially related question: what will happen to a SharedWorker whose cache got updated? Will the repository use a new source for new instances, while the old ones will continue to run? I think the intent of the current spec is that a new instance would not be created provided there is an existing instance already running. How to reload an existing worker to utilize new resources in an updated cache was left as an exercise to the reader. At least that's my understanding of the current spec. 2009/6/1 Drew Wilson atwil...@google.com: 2009/6/1 Alexey Proskuryakov a...@webkit.org 01.06.2009, в 22:37, Drew Wilson написал(а): 1) Since SharedWorkers aren't explicitly tied to a specific Document, it doesn't make sense to have them possibly get loaded from an out-of-date version of the app cache. If you have two separate documents running from different caches, it's weird (and indeterminate) if the version of the cache used to load the SharedWorker script is dependent on which one happens to call new SharedWorker() first. I don't see how exposing DOMApplicationCache methods to workers can help this - a worker will only be able to call DOMApplicationCache.update() after it has started, which is too late. Not sure why that is too late? Can you clarify? Besides, won't the document using an old version of cache break if a newer SharedWorker is suddenly returned to it? The main idea of appcache is that all application resources are versioned, so if we see SharedWorkers as part of application, they should use the same cache version. And if they are independent entities with a stable API, using an out of date version for a while cannot hurt. Why would a document using an old version of cache break if a newer SharedWorker is returned? Why is that any more of a problem than a document using a new version of cache breaking if an older SharedWorker is returned, which is what would happen if SharedWorkers inherited appcache from the first document that instantiated them? It seems like there are several easy options available to apps: 1) Change the name of the shared worker if a non-backward-compatible change needs to be made to the worker script (so new documents don't share the same worker instance as old documents) 2) When updates are available, coordinate updates with all documents so everyone updates at once, possibly exiting the SharedWorker. As for what happens to a SharedWorker whose cache was updated? My presumption is that all future resource loads would use that cache. At that point, the SharedWorker has a few different things it could do: Reload all of its scripts again using importScripts(). This implies that its script loading is idempotent, but that's not too hard to do. Send messages to all of its client documents letting it know that it is shutting down, then invoke close() to shut itself down. The client documents can re-create the SharedWorker the next time they want one. This is inherently race-y, though, since you can't easily coordinate the shutdown of the worker with instantiations of new ones. Do nothing at all All of these options seem quite dangerous - it may be difficult for JS authors to write applications that won't break at update time. It might be tricky, although any application that does dynamic JS loading has to deal with versioning issues already. This is not particularly different. A document can reload itself after updating, but SharedWorkers do not have a way to reload themselves. As you mentioned, they can reload imported scripts (but the main script will remain the same, which would be inconsistent). Why can't they reload the main script? Again, there's a need to be idempotent if you need to maintain some cached state, but it's not totally impossible. Or they can shut down and ask a document to re-create themselves - at which point, we can as well say that the document can update the cache. I'm not arguing against this, I just don't see how it works when you have multiple documents each of which are running from different versions of the app cache, where the shared worker itself is attached to some arbitrary instance. Interaction of SharedWorkers and appcache, explicit or not, sounds like a major
Re: [webkit-dev] AppCache class naming (WAS Re: SharedWorkers alternate design)
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
Re: [webkit-dev] AppCache class naming (WAS Re: SharedWorkers alternate design)
one might reasonably assume that in Chrome, the renderer process is the back end Not really. We do use the terms front and back, but they usually refer to something a bit orthognal to this child/main process distinction... closer to network stack vs closer to browserui is generally what these terms refer to. Anyway... how these terms are used in chromium shouldn't influence our use of these terms in webcore much... in webcore-land we (me at least) were thinking 'front' == closer to script and html content, 'back' == farther away from that. I can make suggestions in the context of reviewing a patch if you guys don't want to discuss it any more. I'm not clear enough on how exactly you split the classes to make a good suggestion. That would be great. Here's a patch... https://bugs.webkit.org/show_bug.cgi?id=25436 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Notifications API
Its a comfortable notion that an origin == application, but the reality is that a single site can host multiple applications, and that an individual application can span multiple origins. We can probably do better than imposing the origin == application model on everybody. The only organizing principles we have for web permission granting are at the page level or at the origin level. Neither of these is particularly satisfying. I think end users would like to see things in terms of applications. The web provides no means of identifying which pages/origins should be considered part of an application. If there was a sense of application'ness, we could apply permissions to them... which is a desirable goal i think. So how to establish a sense of application'ness? html application = urlToAppIdentifyingFile If a page that doesn't identify itself start requesting permissions... fallback on the origin = application model. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Notifications API
but that seems inherent to the general model of the web Agreed, I'm suggesting that model can be improved upon. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
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
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). In my case, I want to reserve the name ApplicationCache for an object that contains a collection of entries which lives strincly in the 'backend'. So i guess that leave me with for following for the front/back splitting related things... ApplicationCacheClient// for the 'frontend' ApplicationCacheServiceProxy // for the front to talk to the back ApplicationCacheService // for the 'backend' ApplicationCacheClientProxy // for the back to talk to the front which works for me just fine. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
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. Thanx for the input, very much appreciate the passing along of design sensibilities prevalent in the project. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
John's point about switching which impl to use at runtime is a good one. For example, I was planning on doing something similar for the ApplicationCacheFrontend interface, but with a difference. I was planning on returning one concrete instance when called on the main thread, and another when called on a worker thread... a runtime decision. I think the interface + static factory approach is generally easier to grok than the FooBase / Foo (elsewhere) approach... jmho. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
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. ___ 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 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 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 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. 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
[webkit-dev] AppCache resource loading in a multi-process world
Hi all, Please refer to https://bugs.webkit.org/show_bug.cgi?id=25436. Alexey and I have been trading messages in that issue. He suggested that I bring this up aspects of that issue on the larger list. I think that the best way forward is to discuss general multi-process loader architecture on the mailing list, with appcache design being a natural part of it. The issue is how to accommodate loading out of an appcache in a multi-process browser. I've been working towards a solution where the main process is the only process with direct access to the appcache data on disk. Please see the bug for details. Thnx Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] AppCache functionality provided by the embedder of webkit
I'm working on the app cache for Chrome. We've decided to hoist most the functionality provided by the app cache into Chrome's main browser process, so we won't be using most of the implementation provided by WebKit. I'd like to work through what changes to make within WebKit/WebCore to allow an embedder pull that off. Any suggestions would be much appreciated. In the code base right now, a single compilation flag enables or disables everything to do with app cache in WebKit, ENABLE(OFFLINE_APPLICATION). This turns on/off the scriptable interface bits as well as the backend implementation within webcore. I think I'd like a way to reuse the scriptable interface related bits provided by webkit, but to slide a chrome specific implementation under that interface. One thought was to separate this single flag into two flags, one for the scriptable interface bits and the other for the back end implementation. ENABLE(APPLICATION_CACHE_INTERFACE) - surfaces the window.applicationCache property - pulls in the DOMApplicationCache.idl file - enables event targeting stuff for DOMApplicationCache - perhaps defines an abstract interface that a c++ class backing DOMApplicationCache scriptable API must implement ENABLE(APPLICATION_CACHE_IMPLEMENTATION) // only valid if INTERFACE is also enabled - turns on the rest of the stuff in webkit for app cache, including a concrete implementation of that abstract interface mentioned above. Does something along these lines make sense, or perhaps there is another way to approach this? Thnx Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] AppCache functionality provided by the embedder of webkit
Good question. In general, we've avoided using WebKit code in what we call the browser process (that's the main process in chrome). I'm not sure how firm that policy is. If we were to utilize significant amounts of webcore code in the browser process, we'd have an interesting conundrum about which thread we'd have webkit consider its main thread. For appcache purposes, this would ideally be some background thread, for other purposes this would ideally be what we call the UI thread in the browser process. Ultimately, I think an arrangement that you're alluding to would be the best answer. A common implementation of the AppCache with clean dependencies and interfaces such that it can be re-used in different environments. I was not gunning to take that on as part of my project in the near term as I think that would be disruptive to Chrome and WebKit alike. But down that road, this is an intriguing idea. On Tue, Apr 7, 2009 at 11:16 AM, Darin Adler da...@apple.com wrote: On Apr 7, 2009, at 10:52 AM, Michael Nordman wrote: We've decided to hoist most the functionality provided by the app cache into Chrome's main browser process, Perhaps other WebKit ports will want a similar structure. Is there a way this code in the main browser process could still be WebKit code, or does it have special requirements that make it need to be Chrome-specific? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] AppCache functionality provided by the embedder of webkit
On Tue, Apr 7, 2009 at 11:27 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 7, 2009, at 10:52 AM, Michael Nordman wrote: I'm working on the app cache for Chrome. We've decided to hoist most the functionality provided by the app cache into Chrome's main browser process, so we won't be using most of the implementation provided by WebKit. I'd like to work through what changes to make within WebKit/WebCore to allow an embedder pull that off. Any suggestions would be much appreciated. One downside of this approach is that, if the application cache ever needs to change, it may be necessary to make changes to two separate implementations hosted in different repositories. In addition, quality-of-implementation improvements to one version won't benefit the other. Please see my response to Darin earlier. There may be an opportunity to replace WebKit's impl of this feature with one that has more manageable dependencies. Perhaps chrome's implementation could be the basis for that replacement which could then be used within webkiit proper and within chrome's browser process. A first step along this path could be enabling somebody to wire in a different implementation that is lagging the current incarnation found in webkit at the moment and not ready for the prime time just yet. Some additional info about Chrome's as yet non-existent impl. It needs to be fairly independent of the core chrome codebase in order for it to be testable in our current testing infrastructure for the layout tests. This is a design constraint which will keep me honest regarding dependencies. It's been a recurring theme for the Chrome team to request hooks to bypass WebKit functionality and replace it with Chrome-specific code that lives outside the WebKit tree. So far this has been mostly for code developed when Chrome was originally a secret project. While we felt it was best to grandfather in the existing carve-outs, in general I believe this is not the best way to move the WebKit project forward. I would not like to see this pattern replicated for newly developed functionality. WebKit could grow a stronger sense of frontend vs backend that don't share an address space for features that require touching browser wide state. The current model for webkit doesn't lend itself well for that. We struggle with that a fair amount. Regards, Maciej In the code base right now, a single compilation flag enables or disables everything to do with app cache in WebKit, ENABLE(OFFLINE_APPLICATION). This turns on/off the scriptable interface bits as well as the backend implementation within webcore. I think I'd like a way to reuse the scriptable interface related bits provided by webkit, but to slide a chrome specific implementation under that interface. One thought was to separate this single flag into two flags, one for the scriptable interface bits and the other for the back end implementation. ENABLE(APPLICATION_CACHE_INTERFACE) - surfaces the window.applicationCache property - pulls in the DOMApplicationCache.idl file - enables event targeting stuff for DOMApplicationCache - perhaps defines an abstract interface that a c++ class backing DOMApplicationCache scriptable API must implement ENABLE(APPLICATION_CACHE_IMPLEMENTATION) // only valid if INTERFACE is also enabled - turns on the rest of the stuff in webkit for app cache, including a concrete implementation of that abstract interface mentioned above. Does something along these lines make sense, or perhaps there is another way to approach this? Thnx Michael ___ 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
