RE: [WebStorage] Concerns on spec section 'Processing Model'
+ Ian Hey Ian, Can you please express your opinion on this as an editor of Web Storage (now Web Database) Spec? Thanks, Laxmi From: Nikunj R. Mehta [mailto:nikunj.me...@oracle.com] Sent: Thursday, July 16, 2009 11:45 PM To: public-webapps WG Cc: Laxmi Narsimha Rao Oruganti Subject: Re: [WebStorage] Concerns on spec section 'Processing Model' The spec should not restrict implementations to any one level of concurrency unless there are specific undesirable effects. Restricting the database to a single writer means that if there are separate workers or background threads working to update non-overlapping portions, then they have to wait for the lone current writer. Implementations can certainly compete to produce the level of concurrency that developers need. Specifically, I propose that the following text [[ If the mode is read/write, the transaction must have an exclusive write lock over the entire database. If the mode is read-only, the transaction must have a shared read lock over the entire database. The user agent should wait for an appropriate lock to be available. ]] be replaced with the following text [[ Multiple read-only transactions may share the same data as long as there is no transaction attempting to write the data being read. The user agent must wait for transactions that are reading some data before allowing a read/write transaction on the same data to continue. ]] Nikunj http://o-micron.blogspot.com On Jul 16, 2009, at 6:46 AM, Laxmi Narsimha Rao Oruganti wrote: [Adding the subject, sorry for spam!] Hey folks, I have few questions on Web Storage Spec. I have checked the content of both latest published spechttp://www.w3.org/TR/webstorage/ and latest editors spechttp://dev.w3.org/html5/webstorage/. And the questions are applicable to both the versions of the spec. Section: 4.4.2 Processing model Text: 1. Open a new SQL transaction to the database, and create a SQLTransactionhttp://www.w3.org/TR/webstorage/#sqltransaction object that represents that transaction. If the mode is read/write, the transaction must have an exclusive write lock over the entire database. If the mode is read-only, the transaction must have a shared read lock over the entire database. The user agent should wait for an appropriate lock to be available. Concerns: - Why is the spec mandating a transaction to take an *exclusive write lock on the entire database*? No database book design mandates it. In fact, many client databases out there don't do this. I guess SQLite does this kind. But that does not mean that all implementations have this nature. I am kind of worried that we are putting implementation in theory. For me they are too separate, there are many ways a database could be designed. Like, log+checkpoint approach, shadow copy, version store, journals ...etc. I guess spec should say what a browser should do and not how. I would be happy to get enlightened. Thanks, Laxmi
Re: Web IDL syntax
I think the “Object”, “TRUE” and “FALSE” keywords should be made lowercase. It seems the lower case object has been used as an interface member in HTMLAppletElement. Probably should we keep Object as it is? Both true and false look fine with me. - Shiki
Re: Web IDL syntax
Shiki Okasaka: I think the “Object”, “TRUE” and “FALSE” keywords should be made lowercase. It seems the lower case object has been used as an interface member in HTMLAppletElement. Probably should we keep Object as it is? Both true and false look fine with me. I’ll think about it. :-) HTMLAppletElement can always have readonly attribute DOMString _object; to avoid conflicting with the reserved word. -- Cameron McCormack ≝ http://mcc.id.au/
Re: DataCache API - editor's draft available
This is very encouraging. It sounds like we agree in principal that the best place for the features represented in the DataCache proposal are extensions to the AppCache corner of the world. My preference would be to keep the official AppCache spec stable right now, but to begin designing those extensions sooner rather than later. This would help inform the architecture of AppCache implementations underway by browser vendors today, and help better inform application teams of what to expect as well. The DataCache proposal is a great starting point. In a sense, specify these extensions on a development branch of the spec. On Wed, Jul 22, 2009 at 10:56 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 22 Jul 2009, Adrian Bateman wrote: My preference would be to see this functionality proposed as an evolution of AppCache. While I can't commit that we would implement it any time soon, it would be included in our considerations and at the very least if we implement AppCache we would try to ensure any architecture we select wouldn't preclude these extensions in the future. With work on the HTML5 spec trying to get it locked down towards a Last Call, adding new features to that document is clearly less desirable and I understand Ian's reluctance to incorporate extensions there. My preference in general would be for us to wait until we have stable, well-tested implementations before adding more features to appcache, but I certainly think that on the long term, appcache should be extended to support more than it does now. As it stands, the model is quite extensible, so I think it would be relatively easy for us to move in that direction in the future. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: DataCache API - editor's draft available
On Jul 22, 2009, at 10:56 PM, Ian Hickson wrote: On Wed, 22 Jul 2009, Adrian Bateman wrote: My preference would be to see this functionality proposed as an evolution of AppCache. While I can't commit that we would implement it any time soon, it would be included in our considerations and at the very least if we implement AppCache we would try to ensure any architecture we select wouldn't preclude these extensions in the future. With work on the HTML5 spec trying to get it locked down towards a Last Call, adding new features to that document is clearly less desirable and I understand Ian's reluctance to incorporate extensions there. My preference in general would be for us to wait until we have stable, well-tested implementations before adding more features to appcache, but I certainly think that on the long term, appcache should be extended to support more than it does now. As it stands, the model is quite extensible, so I think it would be relatively easy for us to move in that direction in the future. Don't we have AppCache implementations in Firefox and Safari? Are there parts of the spec that we don't yet have implementation experience or enough feedback about? I happen to think that work on DataCache should not wait for the long term to arrive. May be it is just me, but I don't see harm in getting to an FPWD on DataCache before HTML5 Last Call. I do agree that we should not create an impression that AppCache is solid, and so am open to suggestions about avoiding that. Nikunj http://o-micron.blogspot.com
Re: DataCache API - editor's draft available
On Thu, 23 Jul 2009, Nikunj R. Mehta wrote: Don't we have AppCache implementations in Firefox and Safari? Are there parts of the spec that we don't yet have implementation experience or enough feedback about? I happen to think that work on DataCache should not wait for the long term to arrive. May be it is just me, but I don't see harm in getting to an FPWD on DataCache before HTML5 Last Call. Moving fast is the main way to introduce bugs into the platform. The Web platform has enough bugs already, we don't need to make it worse. I would be much happier waiting a year even, getting multiple implementations shipped, have lots of sites using them, have the features really well understood by authors and implementors... We need to let enough time pass to make sure there are no latent fundamental design problems, security bugs, performance issues, etc. There's no rush, and there's plenty of other stuff being implemented as well. What we have today is two barely tested implementations with virtually no usage and comparatively little deployment. Let's not get ahead of ourselves. Having said that, it's certainly fine to work on proposals, to bang on ideas for future versions, and so on. I just don't think it's appropriate to work on formalising those ideas yet. Of course, I'm just one person, if the working group wants to go faster, I can't stop y'all. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
