Re: [IndexedDB] Current editor's draft
Nikunj,
On Fri, Jul 9, 2010 at 8:21 PM, Nikunj Mehta nik...@o-micron.com wrote:
From my examples, it was clear that we need different object stores to be
opened in different modes. Currently dynamic scope supports this use case,
i.e., allow mode specification on a per object-store basis. Therefore, unless
we decide to de-support this use case, we would need to add this ability to
static scope transactions if dynamic scope transactions go out of v1.
I would be very grateful if you could help me understand the statement
above. Looking at your examples, we have:
function processShipment(shipment, callback) {
// we need to validate the part exists in this city first and that the
supplier is known
var txn = db.transaction(); //synchronous because requesting locks as I go along
var parts = txn.objectStore(part, IDBObjectStore.READ_ONLY);
var partRequest = parts.get(shipment.part);
partRequest.onerror = shipmentProcessingError;
partRequest.onsuccess = function(event) {
// the required part exists and we have now locked at least that key-value
// so that it won't disappear when we add the shipment.
var suppliers = txn.objectStore(supplier, IDBObjectStore.READ_ONLY);
var supplierRequest = suppliers.get(shipment.supplier);
supplierRequest.onerror = shipmentProcessingError;
supplierRequest.onsuccess = function(event) {
// the required supplier exists and we have now locked that key-value
// so that it won't disappear when we add the shipment.
var shipments = db.objectStore(shipment, IDBObjectStore.READ_WRITE);
var shipmentRequest = shipments.add(shipment);
supplierRequest.onerror = shipmentProcessingError;
shipmentRequest.onsuccess = function(event) {
var txnRequest = event.transaction.commit();
// before the callback, commit the stored record
var key = event.result;
txnRequest.oncommit = function() {
callback(key); // which is the key generated during storage
}
txnRequest.onerror = shipmentProcessingError;
}
}
If I understand things right, this example processes a new shipment:
it checks that the part and supplier exist and then adds the new
shipment to the appropriate object store. And you are claiming that if
we leave dynamic transactions out of v1, then we need to de-support
this use case. Is this correct?
Now, would the code below support the same use case?
function processShipment(shipment, callback) {
// We open a READ_WRITE transaction since we need to update the
shipments object store.
var txnRequest = db.openTtransaction(part, supplier,
shipments, IDBObjectStore.READ_TRANSACTION);
txnRequest.onsuccess = function(event) {
var txn = event.transaction;
var parts = txn.objectStore(part);
var partRequest = parts.get(shipment.part);
partRequest.onsuccess = function(event) {
// the required part exists
var suppliers = txn.objectStore(supplier);
var supplierRequest = suppliers.get(shipment.supplier);
supplierRequest.onsuccess = function(event) {
// the required supplier exists
var shipments = db.objectStore(shipment);
var shipmentRequest = shipments.add(shipment);
shipmentRequest.onsuccess = function(event) {
var key = event.result;
txnRequest.oncommit = function() {
callback(key); // which is the key generated during storage
}
}
}
}
}
So if the above supports the same use case (albeit by allowing less
concurrency), then we dropping dynamic transactions doesn't mean we
lose this use case. Is this right? Are there any other use cases you
think we could lose? I could not find them in your examples.
Thanks,
Andrei
Re: Lifetime of Blob URL
On Mon, Jul 12, 2010 at 5:47 AM, Adrian Bateman adria...@microsoft.comwrote: Making the blob url identical to the lifetime of the blob itself would expose when garbage collection takes place and in general could lead to easy to make mistakes in which the developer had something that work mostly but not always -- your situation below is just one of them. Check out the Jian Li's alternate proposal (see his response to Re: [File API] Recent Updates To Specification + Co-Editor on July 1, I think) that addresses this in a way that addresses your concerns and the gc issue as well. The problem with an explicit revoke call is that people need to know to call it, need to actually call it, and need to know when it is appropriate to call. Many of the same timing issues that cause potential problems with GC also make it hard for web developers to know when to call revoke. When GC occurs is indeterminate and would vary greatly between browsers. Developing features which exposes the gc behavior would lead developers into accidentally relying on browser specific behaviors (which may even break for the same browser during upgrades). As I read Jian's proposal, there is a create call (blob.url would go away), so there would clearly be a revoke (or destroy call). With respect to timing issues, the behavior of revoke with respect to load is clearly defined in his proposal which result in very deterministic behavior. dave
RE: Lifetime of Blob URL
On Monday, July 12, 2010 8:24 AM, David Levin wrote: On Mon, Jul 12, 2010 at 5:47 AM, Adrian Bateman adria...@microsoft.com wrote: Making the blob url identical to the lifetime of the blob itself would expose when garbage collection takes place and in general could lead to easy to make mistakes in which the developer had something that work mostly but not always -- your situation below is just one of them. Check out the Jian Li's alternate proposal (see his response to Re: [File API] Recent Updates To Specification + Co-Editor on July 1, I think) that addresses this in a way that addresses your concerns and the gc issue as well. The problem with an explicit revoke call is that people need to know to call it, need to actually call it, and need to know when it is appropriate to call. Many of the same timing issues that cause potential problems with GC also make it hard for web developers to know when to call revoke. When GC occurs is indeterminate and would vary greatly between browsers. Developing features which exposes the gc behavior would lead developers into accidentally relying on browser specific behaviors (which may even break for the same browser during upgrades). The behaviour would have to be explicitly specified and not left to depend on indeterminate browser implementations. As I read Jian's proposal, there is a create call (blob.url would go away), so there would clearly be a revoke (or destroy call). With respect to timing issues, the behavior of revoke with respect to load is clearly defined in his proposal which result in very deterministic behavior. My apologies. I think I missed this part - please can you provide a link to the full proposal? At what point after I assign the src of an img element can I call revoke? Can I do it immediately after the assignment or do I have to have an onload and onerror handler for every element that uses it? With XHR do I have to wait for readyState 4 or can I call revoke earlier in the process? Is there reference counting so that if I call create twice I have to call revoke twice? Thanks, Adrian.
Re: Lifetime of Blob URL
On Mon, Jul 12, 2010 at 8:39 AM, Adrian Bateman adria...@microsoft.comwrote: On Monday, July 12, 2010 8:24 AM, David Levin wrote: On Mon, Jul 12, 2010 at 5:47 AM, Adrian Bateman adria...@microsoft.com wrote: Making the blob url identical to the lifetime of the blob itself would expose when garbage collection takes place and in general could lead to easy to make mistakes in which the developer had something that work mostly but not always -- your situation below is just one of them. Check out the Jian Li's alternate proposal (see his response to Re: [File API] Recent Updates To Specification + Co-Editor on July 1, I think) that addresses this in a way that addresses your concerns and the gc issue as well. The problem with an explicit revoke call is that people need to know to call it, need to actually call it, and need to know when it is appropriate to call. Many of the same timing issues that cause potential problems with GC also make it hard for web developers to know when to call revoke. When GC occurs is indeterminate and would vary greatly between browsers. Developing features which exposes the gc behavior would lead developers into accidentally relying on browser specific behaviors (which may even break for the same browser during upgrades). The behaviour would have to be explicitly specified and not left to depend on indeterminate browser implementations. Yes. Unfortunately, another way of saying that the url lives as long as the Blob lives is the url lives until the Blob is garbage collected. This exposes a very indeterminate behavior. As I read Jian's proposal, there is a create call (blob.url would go away), so there would clearly be a revoke (or destroy call). With respect to timing issues, the behavior of revoke with respect to load is clearly defined in his proposal which result in very deterministic behavior. My apologies. I think I missed this part - please can you provide a link to the full proposal? At what point after I assign the src of an img element can I call revoke? Can I do it immediately after the assignment or do I have to have an onload and onerror handler for every element that uses it? With XHR do I have to wait for readyState 4 or can I call revoke earlier in the process? http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/.html See point #5 basically once a load has started for a url, that load should succeed and revoke may be called. Is there reference counting so that if I call create twice I have to call revoke twice? I don't think this has been specified, but a simple proposal would be that each create call would result in a unique url. Thanks, Adrian.
RE: Lifetime of Blob URL
On Monday, July 12, 2010 9:32 AM, David Levin wrote: On Mon, Jul 12, 2010 at 8:39 AM, Adrian Bateman adria...@microsoft.com wrote: The behaviour would have to be explicitly specified and not left to depend on indeterminate browser implementations. Yes. Unfortunately, another way of saying that the url lives as long as the Blob lives is the url lives until the Blob is garbage collected. This exposes a very indeterminate behavior. Exactly. So what I'm saying is the spec needs to say more than just that. It needs to make further guarantees. http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/.html See point #5 basically once a load has started for a url, that load should succeed and revoke may be called. 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. Regards, Adrian.
Re: Lifetime of Blob URL
On Mon, Jul 12, 2010 at 9:54 AM, Adrian Bateman adria...@microsoft.comwrote: On Monday, July 12, 2010 9:32 AM, David Levin wrote: On Mon, Jul 12, 2010 at 8:39 AM, Adrian Bateman adria...@microsoft.com wrote: The behaviour would have to be explicitly specified and not left to depend on indeterminate browser implementations. Yes. Unfortunately, another way of saying that the url lives as long as the Blob lives is the url lives until the Blob is garbage collected. This exposes a very indeterminate behavior. Exactly. So what I'm saying is the spec needs to say more than just that. It needs to make further guarantees. http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/.html See point #5 basically once a load has started for a url, that load should succeed and revoke may be called. 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. Regards, Adrian.
Re: Lifetime of Blob URL
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.comwrote: On Monday, July 12, 2010 9:32 AM, David Levin wrote: On Mon, Jul 12, 2010 at 8:39 AM, Adrian Bateman adria...@microsoft.com wrote: The behaviour would have to be explicitly specified and not left to depend on indeterminate browser implementations. Yes. Unfortunately, another way of saying that the url lives as long as the Blob lives is the url lives until the Blob is garbage collected. This exposes a very indeterminate behavior. Exactly. So what I'm saying is the spec needs to say more than just that. It needs to make further guarantees. http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/.html See point #5 basically once a load has started for a url, that load should succeed and revoke may be called. 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 Regards, Adrian.
