Re: [FileAPI] Blob.URN?
On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher da...@chromium.org wrote: Apologies if this has been discussed before, but I'm curious why URN is not a property of Blob. It seems like it would be useful to be able to load a slice of a File. For example, this could be used by an application to fetch all of its subresources out of a single file. IIRC originally it was placed on File since Blobs do not have a content type. However I think there is general agreement that it should be moved to Blob. However it would be great to be able to assign a content type to a Blob. Possibly slice() could take a optional argument. / Jonas
RE: [IndexedDB] Lots of small nits and clarifying questions
Sorry for having disappeared for a while, odata was keeping me busy. I agree with all the clarifications listed in this thread that are required, so I won't redundantly mark each with same here, but I have a few comments on one or two of them below. On Mon, Mar 15, 2010 at 8:14 AM, Jeremy Orlow wrote: On Sat, Mar 13, 2010 at 9:02 AM, Nikunj Mehta nik...@o-micron.com wrote: Thanks for your patience. Most questions below don't seem to need new spec text. On Feb 18, 2010, at 9:08 AM, Jeremy Orlow wrote: 6) The specific ordering of elements should probably be specced including a mix of types. Can you propose spec text for this? What do you think about the text in http://www.w3.org/TR/IndexedDB/#key-construct? If we're only adding long long for v1, then I think language similar to what's there now is probably OK. But now that I think about it, I'm a bit concerned that we might be backing ourselves into a corner for the future. I also noticed that the sort order of JavaScript seems to order it numbers, strings, and then nulls (not strings, numbers, nulls). I wonder if there is some other spec on sort order we can cite rather than rolling our own. I really think that just doing long/strings won't do, even for v1. For non-primary-key indexes we'll need at least Date and number (not just integers) in addition to long/string. Without that there is no ordering by date sent for emails or list price for products or lots of other scenarios where you're caching data coming from a server. 2) What happens when data mutates while you're iterating via a cursor? This is covered by http://www.w3.org/TR/IndexedDB/#dfn-mode That applies to two separate transactions. As far as I can tell, it should be possible to have a cursor open and then delete an element that the cursor is currently traversing all within the same transaction. Am I missing something? I was assuming that within the same transaction you could change rows and those changes would be observable from open cursors. If it happens to be the current row then you won't be able to fetch it anymore but you can still move to the next one and continue scanning (and seeing any new changes that happened since you last moved). 1) Structured clone is going to change over time. And, realistically, UAs won't support every type right away anyway. What do we do when a value is inserted that we do not support? We will evolve the text as and when the same evolves in WebStorage. I don't know of any implementations which have moved away from only allowing strings within WebStorage. I suspect that not fully supporting the structured clone algorithm as specced is one of the reasons for this. As far as I can tell, you're essentially saying that fully supporting the the structured clone algorithm a pre-req for IndexedDB? I guess I can't argue too much with that, but I'm not sure how realistic it is. I know we only half support it at the moment in Chromium. I have the same worry about structured clones...it's right in principle but I can't see implementations converging and that will just hurt interoperability. Unfortunately there doesn't seem to be a well-known middle-ground. JSON is way too restrictive (e.g. no Date). Should we consider defining a subset of structured clones that work (maybe something like Javascript primitives plus Date plus whatever extra we feel we should include such as perhaps File objects)? Thanks -pablo
RE: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)
On Fri, Mar 12, 2010 at 7:26 AM, Jeremy Orlow wrote: On Fri, Mar 12, 2010 at 3:23 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Mar 12, 2010 at 3:04 PM, Kris Zyp k...@sitepen.com wrote: I believe computer science has clearly observed the fragility of passing callbacks to the initial function since it conflates the concerns of the operation with the asynchronous notifications and consequently greatly complicates composability. I don't understand this sentence. I'm pretty sure that you can wrap any callback based API in JavaScript with a promised, differed, etc based API. As Nikunj mentioned earlier, we're more concerned about creating a small API surface area and sticking with well understood API designs rather than eliminating the need for libraries that wrap IndexedDB. Trying to digest this thread, I think we've sort of gone full-circle with the whole promises thing. When looking at the code with the chained then pattern I just love the result, but it seems that we can't get all the way there (and nesting instead of chaining stuff kind of lacks the magic). My take is that either we get the really nice pattern by going all the way or we create a more traditional callback/events-based API and then we build promises on top. Things seem to indicate that frameworks are still cooking on promises, so it may be safe to stay with callbacks/events and just build libraries on top (I would have loved to have this be the thing that saved us from needing a library always...but it seems we'll fall just a bit short). As for callbacks versus events, while now I'm starting to get used to the events hooked up to the result object after the call, the callbacks may be a more natural mechanism for this particular usage. I'm not sure why this is fundamentally broken...would love to see examples or reference. If that's the case, then events are the obvious choice. Thanks -pablo
Re: [IndexedDB] Lots of small nits and clarifying questions
On Tue, Mar 30, 2010 at 9:10 AM, Pablo Castro pablo.cas...@microsoft.comwrote: Sorry for having disappeared for a while, odata was keeping me busy. I agree with all the clarifications listed in this thread that are required, so I won't redundantly mark each with same here, but I have a few comments on one or two of them below. On Mon, Mar 15, 2010 at 8:14 AM, Jeremy Orlow wrote: On Sat, Mar 13, 2010 at 9:02 AM, Nikunj Mehta nik...@o-micron.com wrote: Thanks for your patience. Most questions below don't seem to need new spec text. On Feb 18, 2010, at 9:08 AM, Jeremy Orlow wrote: 6) The specific ordering of elements should probably be specced including a mix of types. Can you propose spec text for this? What do you think about the text in http://www.w3.org/TR/IndexedDB/#key-construct? If we're only adding long long for v1, then I think language similar to what's there now is probably OK. But now that I think about it, I'm a bit concerned that we might be backing ourselves into a corner for the future. I also noticed that the sort order of JavaScript seems to order it numbers, strings, and then nulls (not strings, numbers, nulls). I wonder if there is some other spec on sort order we can cite rather than rolling our own. I really think that just doing long/strings won't do, even for v1. For non-primary-key indexes we'll need at least Date and number (not just integers) in addition to long/string. Without that there is no ordering by date sent for emails or list price for products or lots of other scenarios where you're caching data coming from a server. 2) What happens when data mutates while you're iterating via a cursor? This is covered by http://www.w3.org/TR/IndexedDB/#dfn-mode That applies to two separate transactions. As far as I can tell, it should be possible to have a cursor open and then delete an element that the cursor is currently traversing all within the same transaction. Am I missing something? I was assuming that within the same transaction you could change rows and those changes would be observable from open cursors. If it happens to be the current row then you won't be able to fetch it anymore but you can still move to the next one and continue scanning (and seeing any new changes that happened since you last moved). 1) Structured clone is going to change over time. And, realistically, UAs won't support every type right away anyway. What do we do when a value is inserted that we do not support? We will evolve the text as and when the same evolves in WebStorage. I don't know of any implementations which have moved away from only allowing strings within WebStorage. I suspect that not fully supporting the structured clone algorithm as specced is one of the reasons for this. As far as I can tell, you're essentially saying that fully supporting the the structured clone algorithm a pre-req for IndexedDB? I guess I can't argue too much with that, but I'm not sure how realistic it is. I know we only half support it at the moment in Chromium. I have the same worry about structured clones...it's right in principle but I can't see implementations converging and that will just hurt interoperability. Unfortunately there doesn't seem to be a well-known middle-ground. JSON is way too restrictive (e.g. no Date). Should we consider defining a subset of structured clones that work (maybe something like Javascript primitives plus Date plus whatever extra we feel we should include such as perhaps File objects)? There is some precedent for what you suggest: the spec for LocalStorage already specifies that storing ImageData isn't allowed. ( http://dev.w3.org/html5/webstorage/#the-storage-interface see setItem section.) On the other hand, I'm not sure I like the idea of each API supporting different subsets of the structured clone algorithm. Even if all UAs support the same subset for each API, it still seems fairly confusing to web developers. And I'm guessing that UAs won't be to keen on adding more complex control flow to their structured clone implementations to disallow different parts of the algorithm based on what it's using. Thus any specced subset of the algorithm will probably need to be a MAY not a MUST. I still think we should spec an error to be returned when the UA doesn't fully support the structured clone algorithm and thus can't handle the data provided. I agree it's sub-optimal, but I think it's the pragmatic choice. Especially if the structured clone algorithm ever changes (and thus implementations can fall out of compliance with the spec).
Re: [IndexedDB] Explaining Asynchronous event-style interface
On 3/22/2010 10:49 AM, Shawn Wilsher wrote: On 3/13/2010 1:43 AM, Nikunj Mehta wrote: As specced, it is possible to have multiple concurrent requests at various API entry points, except for the IndexedDatabaseRequest interface. In this particular case, you can only have one request to open a database in a Window object. Given that this is setup kind of work, it does not appear that this limitation amounts to much. If multiple connections to a single DB are required, or if different DBs have to be opened, that would have to be done sequentially, i.e., start a new request only after the previous one completed. This seems like an artificial constraint to me. Is there any reason why we couldn't open up more than one database connection at a time (or at least allow the possibility for a UA to do so). In fact, I realized a use case today that makes this constraint difficult to work around. Say you have two different libraries that use indexedDB. You'll now have to be careful when you initialize each library so they don't try to open a database at the same time. Even then, if they open up databases on the fly, you'd have to be very careful to make sure they don't stomp on each other. Having open return an IDBRequest and not having the request property on IndexedDatabaseRequest would solve this problem. I'm going to prototype an implementation in Mozilla this way to see if any issues come up, but I don't currently foresee any. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [IndexedDB] Explaining Asynchronous event-style interface
On Tue, Mar 30, 2010 at 9:37 PM, Shawn Wilsher sdwi...@mozilla.com wrote: On 3/22/2010 10:49 AM, Shawn Wilsher wrote: On 3/13/2010 1:43 AM, Nikunj Mehta wrote: As specced, it is possible to have multiple concurrent requests at various API entry points, except for the IndexedDatabaseRequest interface. In this particular case, you can only have one request to open a database in a Window object. Given that this is setup kind of work, it does not appear that this limitation amounts to much. If multiple connections to a single DB are required, or if different DBs have to be opened, that would have to be done sequentially, i.e., start a new request only after the previous one completed. This seems like an artificial constraint to me. Is there any reason why we couldn't open up more than one database connection at a time (or at least allow the possibility for a UA to do so). In fact, I realized a use case today that makes this constraint difficult to work around. Say you have two different libraries that use indexedDB. You'll now have to be careful when you initialize each library so they don't try to open a database at the same time. Even then, if they open up databases on the fly, you'd have to be very careful to make sure they don't stomp on each other. Having open return an IDBRequest and not having the request property on IndexedDatabaseRequest would solve this problem. I'm going to prototype an implementation in Mozilla this way to see if any issues come up, but I don't currently foresee any. The implementation I'm working on in WebKit is callback(s passed into each method call) based. I guess this will make it easier to compare and contrast the approaches. J
[IndexedDB] Opening a database with a different description
Hey all, The spec is unspecified as to what we should do when a database is opened with a different description than it was previously opened. I'd assume we'd want to update it, but maybe folks have other ideas. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [FileAPI] Blob.URN?
On Tue, Mar 30, 2010 at 12:22 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher da...@chromium.org wrote: Apologies if this has been discussed before, but I'm curious why URN is not a property of Blob. It seems like it would be useful to be able to load a slice of a File. For example, this could be used by an application to fetch all of its subresources out of a single file. IIRC originally it was placed on File since Blobs do not have a content type. However I think there is general agreement that it should be moved to Blob. However it would be great to be able to assign a content type to a Blob. Possibly slice() could take a optional argument. Adding an optional parameter to slice() sounds attractive indeed. BlobBuilder [1] should probably also have such an optional argument. -Darin [1] http://dev.w3.org/2009/dap/file-system/file-writer.html#the-blobbuilder-interface
Re: [FileAPI] Blob.URN?
On Tue, Mar 30, 2010 at 2:57 PM, Darin Fisher da...@chromium.org wrote: On Tue, Mar 30, 2010 at 12:22 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher da...@chromium.org wrote: Apologies if this has been discussed before, but I'm curious why URN is not a property of Blob. It seems like it would be useful to be able to load a slice of a File. For example, this could be used by an application to fetch all of its subresources out of a single file. IIRC originally it was placed on File since Blobs do not have a content type. However I think there is general agreement that it should be moved to Blob. However it would be great to be able to assign a content type to a Blob. Possibly slice() could take a optional argument. Adding an optional parameter to slice() sounds attractive indeed. BlobBuilder [1] should probably also have such an optional argument. Indeed! / Jonas
Re: [FileAPI] Blob.URN?
There is more than just the mime type when dealing with the URLs. There at least two content headers of interest, Content-Type and Content-Disposition. Whatever mechanism involved should allow for both of these content headers to be set by the web application. On Tue, Mar 30, 2010 at 3:07 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Mar 30, 2010 at 2:57 PM, Darin Fisher da...@chromium.org wrote: On Tue, Mar 30, 2010 at 12:22 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher da...@chromium.org wrote: Apologies if this has been discussed before, but I'm curious why URN is not a property of Blob. It seems like it would be useful to be able to load a slice of a File. For example, this could be used by an application to fetch all of its subresources out of a single file. IIRC originally it was placed on File since Blobs do not have a content type. However I think there is general agreement that it should be moved to Blob. However it would be great to be able to assign a content type to a Blob. Possibly slice() could take a optional argument. Adding an optional parameter to slice() sounds attractive indeed. BlobBuilder [1] should probably also have such an optional argument. Indeed! / Jonas
Re: [FileAPI] Blob.URN?
The only way to get a FileWriter at the moment is from input type=saveas. What is desired is a way to simulate the load of a resource with Content-Disposition: attachment that would trigger the browser's download manager. -Darin On Tue, Mar 30, 2010 at 4:32 PM, Jonas Sicking jo...@sicking.cc wrote: What's the use case for specifying the Content-Disposition mime type. The ones I've heard so far seems better solved using the FileWriter [1] API. [1] http://dev.w3.org/2009/dap/file-system/file-writer.html / Jonas On Tue, Mar 30, 2010 at 4:22 PM, Michael Nordman micha...@google.com wrote: There is more than just the mime type when dealing with the URLs. There at least two content headers of interest, Content-Type and Content-Disposition. Whatever mechanism involved should allow for both of these content headers to be set by the web application. On Tue, Mar 30, 2010 at 3:07 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Mar 30, 2010 at 2:57 PM, Darin Fisher da...@chromium.org wrote: On Tue, Mar 30, 2010 at 12:22 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher da...@chromium.org wrote: Apologies if this has been discussed before, but I'm curious why URN is not a property of Blob. It seems like it would be useful to be able to load a slice of a File. For example, this could be used by an application to fetch all of its subresources out of a single file. IIRC originally it was placed on File since Blobs do not have a content type. However I think there is general agreement that it should be moved to Blob. However it would be great to be able to assign a content type to a Blob. Possibly slice() could take a optional argument. Adding an optional parameter to slice() sounds attractive indeed. BlobBuilder [1] should probably also have such an optional argument. Indeed! / Jonas
