Re: [IndexedDB] Current editor's draft
On Tue, Jul 27, 2010 at 12:22 AM, Jonas Sicking wrote: > On Sat, Jul 24, 2010 at 8:29 AM, Jeremy Orlow 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
Fwd: Web Notification Charter is out for review by W3C Members
FYI. Original Message Subject:Web Notification Charter is out for review by W3C Members Date: Mon, 26 Jul 2010 22:58:14 +0200 From: ext Philippe Le Hegaret To: public-web-notificat...@w3.org Folks, the charter is now out for formal review by the W3C Members until August 23, 2010. Feedback on it is still welcome here but be aware that I won't modify the draft in place while the review is ongoing. I did make some edits before sending it, following internal feedback. Some edits were, I believe, editorials. If some of those raise concerns, please let me know. For those of you who are employed by a W3C Member, please ask your AC Rep to respond to the review at: http://lists.w3.org/Archives/Member/w3c-ac-members/2010JulSep/0013.html Philippe
[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 3:14 AM, Jeremy Orlow wrote: > On Tue, Jul 27, 2010 at 12:22 AM, Jonas Sicking wrote: >> >> On Sat, Jul 24, 2010 at 8:29 AM, Jeremy Orlow 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. >> >> >> 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
Re: [IndexedDB] Current editor's draft
On Tue, Jul 27, 2010 at 4:38 PM, Jonas Sicking wrote: > On Tue, Jul 27, 2010 at 3:14 AM, Jeremy Orlow wrote: > > On Tue, Jul 27, 2010 at 12:22 AM, Jonas Sicking > wrote: > >> > >> On Sat, Jul 24, 2010 at 8:29 AM, Jeremy Orlow > 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 10
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 wrote: > On Tue, Jul 13, 2010 at 7:37 AM, David Levin wrote: > > On Tue, Jul 13, 2010 at 6:50 AM, Adrian Bateman > > wrote: > >> > >> On Monday, July 12, 2010 2:31 PM, Darin Fisher wrote: > >> > On Mon, Jul 12, 2010 at 9:59 AM, David Levin > 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 ? > >> > 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 ri
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 E
