Re: [IndexedDB] Current editor's draft
On Tue, Jul 27, 2010 at 12:22 AM, Jonas Sicking jo...@sicking.cc wrote: On Sat, Jul 24, 2010 at 8:29 AM, Jeremy Orlow jor...@chromium.org wrote: And is it only possible to lock existing rows, or can you prevent new records from being created? There's no way to lock yet to be created rows since until a transaction ends, its effects cannot be made visible to other transactions. So if you have an objectStore with auto-incrementing indexes, there is the possibility that two dynamic transactions both can add a row to said objectStore at the same time. Both transactions would then add a row with the same autogenerated id (one higher than the highest id in the table). Upon commit, how is this conflict resolved? What if the objectStore didn't use auto-incrementing indexes, but you still had two separate dynamic transactions which both insert a row with the same key. How is the conflict resolved? I believe a common trick to reconcile this is stipulating that if you add 1000 rows the id's may not necessarily be 1000 sequential numbers. This allows transactions to increment the id and leave it incremented even if the transaction fails. Which also means that other transactions can be grabbing an ID of their own as well. And if a transaction fails, well, we've wasted one possible ID. This does not answer the question what happens if two transactions add the same key value though? If you're using optimistic transactions, whichever commits first succeeds. Not sure with the pessimistic/lock-based implementations. And is it possible to only use read-locking for some rows, but write-locking for others, in the same objectStore? An implementation could use shared locks for read operations even though the object store might have been opened in READ_WRITE mode, and later upgrade the locks if the read data is being modified. However, I am not keen to push for this as a specced behavior. What do you mean by an implementation could? Is this left intentionally undefined and left up to the implementation? Doesn't that mean that there is significant risk that code could work very well in a conservative implementation, but often cause race conditions in a implementation that uses narrower locks? Wouldn't this result in a race to the bottom where implementations are forced to eventually use very wide locks in order to work well in websites? In general, there are a lot of details that are unclear in the dynamic transactions proposals. I'm also not sure if these things are unclear to me because they are intentionally left undefined, or if you guys just haven't had time yet to define the details? As the spec is now, as an implementor I'd have no idea of how to implement dynamic transactions. And as a user I'd have no idea what level of protection to expect from implementations, nor what strategies to use to avoid bugs. In all the development I've done deadlocks and race conditions are generally unacceptable, and instead strategies are developed that avoids them, such as always grab locks in the same order, and always grab locks when using shared data. I currently have no idea what strategy to recommend in IndexedDB documentation to developers to allow them to avoid race conditions and deadlocks. To get clarity in these questions, I'd *really* *really* like to see a more detailed proposal. I think a detailed proposal would be a good thing (maybe from Pablo or Nikunj since they're who are really pushing them at this point), but at the same time, I think you're getting really bogged down in the details, Jonas. What we should be concerned about and speccing is the behavior the user sees. For example, can any operation on data fail due to transient issues (like deadlocks, serialization issues) or will the implementation shield web developers from this? And will we guarantee 100% serializable semantics? (I strongly believe we should on both counts.) How things are implemented, granularity of locks, or even if an implementation uses locks at all for dynamic transactions should be explicitly out of scope for any spec. After all, it's only the behavior users care about. If we can guarantee no deadlocks and 100% serializable semantics, then I agree, it doesn't matter beyond that. However I don't think the current proposals for dynamic transactions guarantee that. In fact, a central point of the dynamic transactions proposal seems to be that the author can grow the lock space dynamically, in an author defined order. As long as that is the case you can't prevent deadlocks other than by forbidding multiple concurrent (dynamic) transactions. There has been a lot of talk on list about how you could implement dynamic transactions with locks and I agree that I don't see how what's been mentioned can be guaranteed to be serializable and/or not create deadlocks.
[widgets] Next call is August 5
Because of vacations and conflicting meetings, the next widgets call will be August 5 (draft agenda will be posted on August 4). Open actions and issues for the widget product: http://www.w3.org/2008/webapps/track/products/8 Minutes from last call: http://www.w3.org/2010/07/08-wam-minutes.html -Art Barstow
Re: [xhr] RFC2617 Digest authentication
Please correct me if I'm wrong, but as I read the XHR level 2 draft, it seems impossible to do Digest auth with custom mechanism for acquiring the authentication credentials. I.e. supplying your own login dialog. To correctly digest authenticate, one needs to be challenged by the server first. To do that one needs to attempt to invoke a method on a resource without, or with invalid credentials. The resulting 401 Unauthorized reply then contains the challenge with nonce, opaque, etc. values required to produce correct reply. In order to inhibit the browser from prompting the credentials from user, one must define user, password in call to open() method. My observations show this will produce a basic Authenticate: header in the request thus leaking the user/password out in the open even though the server might refuse Basic auth. Many servers do and should refuse HTTP Basic auth over a non-encrypted connection. This is required by WebDAV [1], for example. Now it may be possible to trick some of the clients into Digest authentication without prompting the user by first calling open() with bogus user/password - then catching the 401 reply and on subsequent try call open() again with correct user/password values, hoping that the client cached the challenge. This would qualify as a hack, though, since AFAIK this behaviour is not prescribed by the Draft. I have no problem with rolling my own Digest authentication routines in the client but this would require a clean flag in the XHR to disable any attempt to do authentication on its behalf. Then again, another flag forcing the XHR to only authenticate when challenged, and then choose the strongest available method, as required by rfc2617 [2] would be preferable and would make it easier for developers to use a standard authentication method, reusing what's already implemented in most (modern) clients. Yrjänä [1] http://www.webdav.org/specs/rfc4918.html#rfc.section.20.1 [2] http://tools.ietf.org/html/rfc2617#section-4.6 -- Yrjana Rankka| gh...@openlinksw.com Developer, Virtuoso Team | http://www.openlinksw.com | Making Technology Work For You
Re: [IndexedDB] Current editor's draft
On Tue, Jul 27, 2010 at 4:38 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Jul 27, 2010 at 3:14 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Jul 27, 2010 at 12:22 AM, Jonas Sicking jo...@sicking.cc wrote: On Sat, Jul 24, 2010 at 8:29 AM, Jeremy Orlow jor...@chromium.org wrote: And is it only possible to lock existing rows, or can you prevent new records from being created? There's no way to lock yet to be created rows since until a transaction ends, its effects cannot be made visible to other transactions. So if you have an objectStore with auto-incrementing indexes, there is the possibility that two dynamic transactions both can add a row to said objectStore at the same time. Both transactions would then add a row with the same autogenerated id (one higher than the highest id in the table). Upon commit, how is this conflict resolved? What if the objectStore didn't use auto-incrementing indexes, but you still had two separate dynamic transactions which both insert a row with the same key. How is the conflict resolved? I believe a common trick to reconcile this is stipulating that if you add 1000 rows the id's may not necessarily be 1000 sequential numbers. This allows transactions to increment the id and leave it incremented even if the transaction fails. Which also means that other transactions can be grabbing an ID of their own as well. And if a transaction fails, well, we've wasted one possible ID. This does not answer the question what happens if two transactions add the same key value though? If you're using optimistic transactions, whichever commits first succeeds. Not sure with the pessimistic/lock-based implementations. That doesn't count as serializable, does it? It's not a dead-lock hazard, but a race condition where whoever commits last experiences dataloss unless properly handling the commit error. If they don't handle commit errors, yes, you would have data loss. I didn't realize we were even considering trying to make dynamic transactions work without the possibility of the commit failing. And is it possible to only use read-locking for some rows, but write-locking for others, in the same objectStore? An implementation could use shared locks for read operations even though the object store might have been opened in READ_WRITE mode, and later upgrade the locks if the read data is being modified. However, I am not keen to push for this as a specced behavior. What do you mean by an implementation could? Is this left intentionally undefined and left up to the implementation? Doesn't that mean that there is significant risk that code could work very well in a conservative implementation, but often cause race conditions in a implementation that uses narrower locks? Wouldn't this result in a race to the bottom where implementations are forced to eventually use very wide locks in order to work well in websites? In general, there are a lot of details that are unclear in the dynamic transactions proposals. I'm also not sure if these things are unclear to me because they are intentionally left undefined, or if you guys just haven't had time yet to define the details? As the spec is now, as an implementor I'd have no idea of how to implement dynamic transactions. And as a user I'd have no idea what level of protection to expect from implementations, nor what strategies to use to avoid bugs. In all the development I've done deadlocks and race conditions are generally unacceptable, and instead strategies are developed that avoids them, such as always grab locks in the same order, and always grab locks when using shared data. I currently have no idea what strategy to recommend in IndexedDB documentation to developers to allow them to avoid race conditions and deadlocks. To get clarity in these questions, I'd *really* *really* like to see a more detailed proposal. I think a detailed proposal would be a good thing (maybe from Pablo or Nikunj since they're who are really pushing them at this point), but at the same time, I think you're getting really bogged down in the details, Jonas. What we should be concerned about and speccing is the behavior the user sees. For example, can any operation on data fail due to transient issues (like deadlocks, serialization issues) or will the implementation shield web developers from this? And will we guarantee 100% serializable semantics? (I strongly believe we should on both counts.) How things are implemented, granularity of locks, or even if an implementation uses locks at all for dynamic transactions should be explicitly out of scope for any spec. After all, it's only the behavior users care about. If we can guarantee no deadlocks and
Re: Lifetime of Blob URL
Thanks Jonas, Just to clarify some details we had while discussing this, could you confirm if this matches with your thinking (or not): 1. If blob was created in window1, blob.url was queried, then passed (as JS object) to window2, and window1 was closed - then the url gets invalidated when window1 is closed, but immediately re-validated if window2 queries blob.url. The url string is going to be the same, only there will be a time interval between closing window1 and querying blob.url in window2, during which loading from the url returns 404. 2. If blob is sent to a Worker via worker.postMessage(blob), the 'structured clone' mechanism is used, so on the other side of postMessage a new blob object is created, backed by the same data, but having its own unique blob.url string (and separate lifetime). Dmitry On Mon, Jul 26, 2010 at 2:12 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Jul 13, 2010 at 7:37 AM, David Levin le...@google.com wrote: On Tue, Jul 13, 2010 at 6:50 AM, Adrian Bateman adria...@microsoft.com wrote: On Monday, July 12, 2010 2:31 PM, Darin Fisher wrote: On Mon, Jul 12, 2010 at 9:59 AM, David Levin le...@google.com wrote: On Mon, Jul 12, 2010 at 9:54 AM, Adrian Bateman adria...@microsoft.com wrote: I read point #5 to be only about surviving the start of a navigation. As a web developer, how can I tell when a load has started for an img? Isn't this similarly indeterminate. As soon as img.src is set. the spec could mention that the resource pointed by blob URL should be loaded successfully as long as the blob URL is valid at the time when the resource is starting to load. Should apply to xhr (after send is called), img, and navigation. Right, it seems reasonable to say that ownership of the resource referenced by a Blob can be shared by a XHR, Image, or navigation once it is told to start loading the resource. -Darin It sounds like you are saying the following is guaranteed to work: img.src = blob.url; window.revokeBlobUrl(blob); return; If that is the case then the user agent is already making the guarantees I was talking about and so I still think having the lifetime mapped to the blob not the document is better. This means that in the general case I don't have to worry about lifetime management. Mapping lifetime to the blob exposes when the blob gets garbage collected which is a very indeterminate point in time (and is very browser version dependent -- it will set you up for compatibility issues when you update your javascript engine -- and there are also the cross browser issues of course). Specifically, a blob could go out of scope (to use your earlier phrase) and then one could do img.src = blobUrl (the url that was exposed from the blob but not using the blob object). This will work sometimes but not others (depending on whether garbage collection collected the blob). This is much more indeterminate than the current spec which maps the blob.url lifetime to the lifetime of the document where the blob was created. When thinking about blob.url lifetime, there are several problems to solve: 1. An AJAX style web application may never navigate the document and this means that every blob for which a URL is created must be kept around in some form for the lifetime of the application. 2. A blob passed to between documents would have its blob.url stop working as soon as the original document got closed. 3. Having a model that makes the url have a determinate lifetime which doesn't expose the web developer to indeterminate behaviors issues like we have discussed above. The current spec has issues #1 and #2. Binding the lifetime of blob.url to blob has issue #3. Indeed. I agree with others that have said that exposing GC behavior is a big problem. I think especially here where a very natural usage pattern is to grab a File object, extract its url, and then drop the reference to the File object on the floor. And I don't think specifying how GC is supposed to work is a workable solution. I doubt that any browser vendor will be willing to lock down their GC to that degree. GC implementations is a very active area of experimentation and has been for many many years. I see no reason to think that we'd be able to come up with a GC algorithm that wouldn't be obsolete very soon. However I also don't think #3 above is a huge problem. You can always flush a blob to disk, meaning that all that is leaked is an entry in a url-filename hash table. No actual data needs to be kept in memory. It's definitely still a problem, but I figured it's worth pointing out. Given that, I see no other significantly different solution than what is in the spec right now. Though there are definitely some problems that we should fix: 1. Add a function for destroying a url reference seems like a good idea. 2. #2 above can be
Re: LCWD comments
On Thu, 1 Jul 2010, Krzysztof Maczy�~Dski wrote: [a] http://www.w3.org/TR/2009/WD-eventsource-20091222/ 0. In [a]: The W3C Web Apps Working Group It's either WebApps or Web Applications according to the charter. Fixed. 1. [a] references HTML5 which is unlikely to go to Rec any time soon. What path do you envision following to resolve this? Waiting. There's no rush to get to REC. 2. In [a]: HTTP 302 Found, 303 See Other, and 307 Temporary Redirect responses must cause the user agent to connect to the new server-specified URL, but if the user agent needs to again request the resource at a later point, it must return to the previously specified URL for this event source. Does it include only requesting a representation of the resource using the same EventSource object, the same browsing context, or globally (as long as the UA remembers having requested it before)? Is this consistent (especially for 303) with HTTP semantics? Clarified. 3. In [a]: Any other HTTP response code not listed here, and any network error that prevents the HTTP connection from being established in the first place (e.g. DNS errors), must cause the user agent to fail the connection. I'm unsure whether it doesn't violate semantics of some HTTP codes already defined. But it surely imposes limits on what future codes may indicate, flying in the face of this extensibility point. All that this spec should say about the potentially coming unknown is that semantics of other codes must be applied as required for them. That doesn't seem like it would lead to great interoperability in the face of errorneous servers. 4. text/event-stream uses text before / which is inappropriate and should be application. Entities of type text must be, at least as the last resort, feasible for rendering to the user as text (which not any sequence of octets is, e.g. text/html, but application/msword). text/event-stream can be rendered to the user, it's just text. 5. In [a]: formats of event framing defined by other applicable specifications may be supported What is event framing? A structure for demarking events. Additionally, are we going to have „other applicable specifications” extension point everywhere? It's what pretty much everything on the Web uses, from IP all the way to JS, so apparently yes. For the moment it's just a beast dwelling in the HTML5 spec, tolerated until it gets its extensibility story straight, but if it's going to affect other specs in this way, the TAG should certainly have a look. I don't understand. This is how all specs are extended. Are you just referring to it being explicit? It seems better to be explicit rather than leaving things implied like most specs do. 6. Section 10 of [a] seems something new in W3C's LCs. What is the story behind specifying requirements on finalization (note that this name is better, since garbage collection looks like limiting this behaviour to environments with a GC) and some rules stating when a spec should include them? The story is that it is needed in this case so as to define behaviour that is interoperably implementable. Has there been any architectural discussion about it? What is architectural discussion? [b] http://www.w3.org/TR/2009/WD-webstorage-20091222/ 7. In [b]: The term JavaScript is used to refer to ECMA262, rather than the official term ECMAScript, since the term JavaScript is more widely known. The term JavaScript already refers to a proprietary implementation of ECMAScript. A confusion should not be entrenched further just because it's common. Clarity will be appreciated by intended readers of the spec, of whom knowledge of this distinction can be safely assumed. The term is unused anyway. This is just part of the boilerplate used in specs that are really sections of the WHATWG Web Apps 1.0 spec published through the WebApps WG. 8. In [b]: To mitigate this, pages can use SSL. Please change to TLS which is the standard name. Fixed. 9. [b] states more precise requirements on scripts running in the context of an HTMLDocument than otherwise. Should some of them apply more widely? I don't understand the question. [c] http://www.w3.org/TR/2009/WD-workers-20091222/ 10. In [c]: the MIME type of the script is ignored This is a new spec. It shouldn't be plagued with such idiosyncratic legacy mechanisms. It's a new spec that has to work with existing deployed content. 11. In [c]: there is no way to override the type. It's always assumed to be JavaScript. This is a violation of orthogonality for no real benefit. The benefit is simplicity. 12. In [c]: If there are any outstanding transactions that have callbacks What's a transaction, when has it got a callback? Added a reference. 13. Why does [c] define ErrorEvent instead of reusing DOMError? Primarily because DOMError is not an event. Besides, it uses a
