[admin] Publishing specs before EoY; CfC start deadline is December 2
Hi Editors, All, If we want to publish a WD or LCWDin #TR before the EoY, given the upcoming publishing blackout dates, the schedule and deadlines are: * December 2 - deadline to start a (1-week) CfC * December 9 - CfC end date * December 11 - deadline for publication request * December 13 - last day to publish The above deadlines also apply for CRsand PRs but since those publications require some additional steps (e.g. a Director's call), the CfC will need to start earlier- this week. If a spec was last published as a FPWD and new features have been added, please consider a CfC for a new WD. If a spec was last published as a WD, and it is feature complete and/or is getting implemented, please consider a CfC for LCWD. Please let me know if you want me to start a CfC. -Thanks, AB #TR http://www.w3.org/TR/
Re: [IndexedDB] Can IDBTransaction.oncomplete callback be used as active state?
On Sun, Nov 18, 2012 at 7:29 AM, Kyaw Tun kyaw...@yathit.com wrote: Transaction is active as long as I send request from the IDBRequest callback. Is there any other way to prevent committing? No. If at any point your JavaScript finishes executing there are no running or pending requests the transaction becomes inactive. If there any way to detect transaction active flag? Not directly. Attempting to place a new request will fail with a TransactionInactiveError though. I expect IDBTransaction.oncomplete callback can be used to flag inactive state, but it is not according to my few test. Transaction is already inactive and cannot be use even before receiving oncomplete callback. oncomplete is called after the transaction is committed. The transition from active to inactive is what starts committing the transaction, so oncomplete is far too late to determine that. - Kyle
Re: [IndexedDB] coupled transactions
On Sun, Nov 18, 2012 at 7:54 AM, Kyaw Tun kyaw...@yathit.com wrote:
Coupled transactions exists when two or more transactions should be
committed together but transactions are in different scopes or mode.
Currently I find this problem challenging to solve with IndexedDB API.
This can be solved by merging transactions into single transaction,
but it will be sub-optimal and require sharing transaction objects.
The use case appear when we want to use producer-consumer pattern as
follow:
In producer object, a read transaction is created and index cursors
are scanning to find a matching keys. Whenever it find a match key, it
send to consumer object.
Consumer object, a read or write transaction is created when it first
received a key. The cursor value is use to render UI or update it to
the database. In general, we are expecting to receive ordered sequence
of keys. For optimal purpose, the transaction should be keep active.
Concrete example:
Consumer side
--
var out = new ydn.db.Streamer(db, 'animals', 'id');
out.setSink(function(key, value) {
console.log(['receiving', key, value]); // should be ['cow', 'cow']
});
Producer side
var q1 = ydn.db.Iterator.where('animals', 'color', '=', 'spots');
var q2 = ydn.db.Iterator.where('animals', 'horn', '=', 1);
var q3 = ydn.db.Iterator.where('animals', 'legs', '=', 4);
var solver = new ydn.db.algo.NestedLoop(out);
var req = db.scan([q1, q2, q3], solver);
data
--
animals = [
{id: 'rat', color: 'brown', horn: 0, legs: 4},
{id: 'cow', color: 'spots', horn: 1, legs: 4},
{id: 'galon', color: 'gold', horn: 1, legs: 2},
{id: 'snake', color: 'spots', horn: 0, legs: 0},
{id: 'chicken', color: 'red', horn: 0, legs: 2}
];
Ref: test_31_scan_mutli_query_match in
https://bitbucket.org/ytkyaw/ydn-db/raw/0e1e33582cfed54c9baf1d5bb134cae58bac45c8/test/iteration_test.js
I don't understand why the two transactions need to be coupled. The
producer object has a read only transaction, so it won't commit any
changes. The consumer object has a read write transaction. If it's
modifying the same object stores the producer object is reading from, that
transaction will block until the producer's transaction is inactive, so the
producer will receive a coherent snapshot of data.
- Kyle
Re: [webcomponents]: Changing API from constructable ShadowRoot to factory-like
I made the change to the editor's draft: http://dvcs.w3.org/hg/webcomponents/rev/e0dfe2ac8104 You can read the shiny new parts of the spec here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#extensions-to-element Please let me know if I goofed up something, preferably by filing bugs :) :DG
