Re: publish new Working Draft of Indexed Database API; deadline April 16
On Tue, Apr 19, 2011 at 6:41 PM, Eliot Graff eliot.gr...@microsoft.com wrote: Thanks for the feedback. Moving forward, I will track changes and resolution of these suggestions in bug 9379 [1]. ok Appreciate the time you've spent on this. here's next next part, note that i drafted it a while ago and am just sending it to flush my mailbox. http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html part two... The transaction mode determines both which operations are allowed to be performed during the transaction, as well whether two transactions can run concurrently or not. The transaction mode controls whether or not multiple transactions can run currently and which operations may be performed during the transaction. Which operations are allowed be be performed are The allowed operations are defined in detail below, but in general transactions opened in READ_ONLY mode are only allowed to perform reading operations which does not change data. s/reading // s/does/do/ -- this defines read, and operations are plural.. if you really want to define it perhaps stick some quotes around reading? READ_WRITE transactions are allowed to perform reading and writing transactions to existing object stores, s/perform reading and writing/read from and write/ where as VERSION_CHANGE transactions are allowed to perform any operations, including ones that delete and create object stores and indexes. As long as the VERSION_CHANGE transaction, the implementation s/transaction/transaction is pending/ ? MUST wait with starting any other transactions against the same s/with/before/ database until the VERSION_CHANGE transaction is finished. There are a number of ways that an implementation ensure this. s/ensure/ensures/ It can prevent READ_WRITE transactions whose scope overlap s/prevent/stall/ ? (you don't prevent them from ever existing, you at best prevent them from starting which seems more like stalling or delaying) s/overlap/overlaps/ the scope of the READ_ONLY transaction from starting until the READ_ONLY transaction is finished. s/is finished/finishes/ Or it can allow the READ_ONLY transaction to see a snapshot of the contents of the object stores which is taken when the READ_ONLY transaction is started. s/is // Similarly, implementations MUST ensure that a READ_WRITE transaction is only affected by changes to object stores that are made using the transaction itself. I.e. the implementation MUST ensure that another transaction does not modify the contents of object stores in the READ_WRITE transactions scope. I don't think starting a sentence with i.e. is a good idea... s/transactions/transaction's/ The implementation MUST also ensure that if the READ_WRITE transaction completes successfully, that the changes written to object stores using the s/, that / / transaction can be committed to the database without merge conflicts. i find can be here problematic, i know it's only meaningful with the next sentence, but i don't think it works well. An implementation MUST NOT abort a transaction due to merge conflicts. An implementation MUST NOT start any transaction until all other READ_WRITE transactions with overlapping scope have completed. doesn't this prevent merge conflicts? When multiple transactions are eligible to be started, older transactions should be started first. should 'should' be written as an RFC word? User agents MUST ensure a reasonable level of fairness across transactions to prevent starvation. For example if multiple READ_ONLY transaction are started one after another the implementation MUST ensure that that doesn't indefinitely prevent a pending READ_WRITE transaction from starting. This MUST doesn't seem testable, and sticking a MUST into an example seems wrong. Transaction objects implement Each transaction object will implement either the IDBTransaction or the IDBTransactionSync interfaces. interface. -- this is a style change and applies to other objects in this document. I'm assuming that an object only ever implements one of the two interfaces and thus interface should be singular and you should spell out that it's exclusive. If it isn't, I'd like to know how/why. Every request also has a result and an errorCode, neither of which are accessible until the done flag is set to true. does 'are accessible' mean will throw an exception if poked? Finally, requests have a request transaction. When a request is created, it is always placed against a transaction using either the steps to a asynchronously execute a request or the steps to a synchronously execute a request. It would be really helpful if things like steps to whatever were links This sets the request transaction to be that request. s/This sets/Those steps set/ The only exceptions to this are the request returned from a IDBFactory.open call and the request returned from a IDBDatabase.setVersion call, which create requests
RE: publish new Working Draft of Indexed Database API; deadline April 16
Hi Josh. Thanks for the feedback. Moving forward, I will track changes and resolution of these suggestions in bug 9379 [1]. Appreciate the time you've spent on this. Eliot [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9739 -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps- requ...@w3.org] On Behalf Of timeless Sent: Tuesday, April 12, 2011 12:32 AM To: Arthur Barstow Cc: public-webapps Subject: Re: publish new Working Draft of Indexed Database API; deadline April 16 On Sat, Apr 9, 2011 at 2:22 PM, Arthur Barstow art.bars...@nokia.com wrote: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html I expect this message to only have editorial comments. However, I'm not fond of April 16th, this month is tax month and I still need to file. Transaction A transaction is used to interact with the data in a database. Whenever data is read or written to the database this is done using a transaction. maybe s/this/it/ All transactions are created using a connection, I don't like using, perhaps from? -- I haven't gotten to the API yet. I'm also uncertain about 'a connection' vs. 'connections' which is the transactions connection. s/transactions/transaction's/ The transaction has a mode which determines which types of interactions can be performed using the transaction. s/using the transaction/upon it/ ? -- The transaction also started the sentence. The mode is set when the transaction is created and remains constant for the s/constant/fixed/ lifetime of the transaction. s/lifetime/life/ The transaction also has a scope which determines which object stores the transaction can interact with. s/which.*with/the object stores with which the transaction may interact/. Finally, transactions have a active flag, s/ a / an / s/Finally, t/T/ -- It isn't Finally -- Finally is used again in the next sentence. which determines if new requests can currently be placed against the transaction. The prose here implies that this is mutable, it's also awkward (probably he use of 'currently'). Finally, transactions also contain a request list of requests which have been placed against the transaction. It seems that placed is treated as technical language, I'd expect it to be defined somewhere (or globally replaced by 'made'). Transactions have a constant scope which is determined when the transaction is created and remains constant for the lifetime of the transaction. Each transaction has a fixed scope determined at creation time. Transactions offer some protection from application and system failures. A transaction represents an atomic and durable set of data access and mutation operations. I know that data can be uncountable or plural, but I'm unsure that 'access' fits with its use here -- should it be 'accesses'? This is encouraged using the automatically committing functionality described below. s/using the automatically/by the automatic/ Authors can still cause transactions to run for a long time, however this is generally not a usage pattern which is recommended s/usage pattern which is recommended/a recommended usage pattern/ and can lead to bad user experience in some implementations. possibly a bad user experience | bad user experiences ? A transaction is created using IDBDatabase.transaction. The arguments passed determine what the scope of the transaction is s/what//; s/is// and whether it's read only or not. whether or not it is read-only. When a transaction is created its active flag is initially set to true. The implementation MUST allow requests to be placed against the transaction whenever the active flag is true. This is the case even if the transaction has not yet been started. Until the transaction is started the implementation MUST NOT execute these requests, but the implementation MUST still keep track of the requests and their order. s/, but/;/ s/still// Requests may only be placed against the transaction s/the/a/ while the transaction is active. s/the transaction/it/ If a request is attempted to be placed against a transaction when I find request/attempted/placed awkward, possibly because it lacks an actor... it is not active, I believe not active is used here to be the technical state not active, perhaps it should be marked up. Otherwise as this is prose, I'd use inactive. the implementation MUST reject the attempt by throwing a TRANSACTION_INACTIVE_ERR exception. Inactive is used in the exception type, it's a valid English word Once an implementation is able to enforce the constraints defined for the mode of the transaction, transaction mode defined below, the implementation MUST asynchronously start the transaction. When this happens is affected by the mode in which the transaction is opened, and which
Re: publish new Working Draft of Indexed Database API; deadline April 16
On Sat, Apr 9, 2011 at 2:22 PM, Arthur Barstow art.bars...@nokia.com wrote: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html I expect this message to only have editorial comments. However, I'm not fond of April 16th, this month is tax month and I still need to file. Transaction A transaction is used to interact with the data in a database. Whenever data is read or written to the database this is done using a transaction. maybe s/this/it/ All transactions are created using a connection, I don't like using, perhaps from? -- I haven't gotten to the API yet. I'm also uncertain about 'a connection' vs. 'connections' which is the transactions connection. s/transactions/transaction's/ The transaction has a mode which determines which types of interactions can be performed using the transaction. s/using the transaction/upon it/ ? -- The transaction also started the sentence. The mode is set when the transaction is created and remains constant for the s/constant/fixed/ lifetime of the transaction. s/lifetime/life/ The transaction also has a scope which determines which object stores the transaction can interact with. s/which.*with/the object stores with which the transaction may interact/. Finally, transactions have a active flag, s/ a / an / s/Finally, t/T/ -- It isn't Finally -- Finally is used again in the next sentence. which determines if new requests can currently be placed against the transaction. The prose here implies that this is mutable, it's also awkward (probably he use of 'currently'). Finally, transactions also contain a request list of requests which have been placed against the transaction. It seems that placed is treated as technical language, I'd expect it to be defined somewhere (or globally replaced by 'made'). Transactions have a constant scope which is determined when the transaction is created and remains constant for the lifetime of the transaction. Each transaction has a fixed scope determined at creation time. Transactions offer some protection from application and system failures. A transaction represents an atomic and durable set of data access and mutation operations. I know that data can be uncountable or plural, but I'm unsure that 'access' fits with its use here -- should it be 'accesses'? This is encouraged using the automatically committing functionality described below. s/using the automatically/by the automatic/ Authors can still cause transactions to run for a long time, however this is generally not a usage pattern which is recommended s/usage pattern which is recommended/a recommended usage pattern/ and can lead to bad user experience in some implementations. possibly a bad user experience | bad user experiences ? A transaction is created using IDBDatabase.transaction. The arguments passed determine what the scope of the transaction is s/what//; s/is// and whether it's read only or not. whether or not it is read-only. When a transaction is created its active flag is initially set to true. The implementation MUST allow requests to be placed against the transaction whenever the active flag is true. This is the case even if the transaction has not yet been started. Until the transaction is started the implementation MUST NOT execute these requests, but the implementation MUST still keep track of the requests and their order. s/, but/;/ s/still// Requests may only be placed against the transaction s/the/a/ while the transaction is active. s/the transaction/it/ If a request is attempted to be placed against a transaction when I find request/attempted/placed awkward, possibly because it lacks an actor... it is not active, I believe not active is used here to be the technical state not active, perhaps it should be marked up. Otherwise as this is prose, I'd use inactive. the implementation MUST reject the attempt by throwing a TRANSACTION_INACTIVE_ERR exception. Inactive is used in the exception type, it's a valid English word Once an implementation is able to enforce the constraints defined for the mode of the transaction, transaction mode defined below, the implementation MUST asynchronously start the transaction. When this happens is affected by the mode in which the transaction is opened, and which object stores are included in scope of the transaction. s/which/the/ s/are// s/scope of the transaction/the transaction's scope/ Once the transaction has been started the implementation can start executing the requests placed against the transaction. Unless otherwise defined requests MUST be executed in the order they are placed against the transaction. s/they/in which they/ s/are/were/ I find placed against strange. made against seems to work Otherwise placed into Likewise, their result MUST be returned in the order the request was placed against a specific transaction. result appears to be used as a mass noun, but request is singular, I'm pretty
RE: publish new Working Draft of Indexed Database API; deadline April 16
On Saturday, April 09, 2011 4:23 AM, Arthur Barstow wrote: The Editors of the Indexed Database API would like to publish a new Working Draft of their spec and this is a Call for Consensus to do so: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html If one agrees with this proposal, it: a) indicates support for publishing a new WD; and b) does not necessarily indicate support for the contents of the WD. If you have any comments or concerns about this proposal, please send them to public-webapps by April 16 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. Microsoft supports this.
