Re: [XHR2] ArrayBuffer support added
On Thu, 03 Feb 2011 23:56:13 +0100, Charles Pritchard ch...@jumis.com wrote: But in the present, we've got XMLHttpRequest, with CORS semantics, and all other manner of goodness. EventSource seems to me, to have different use cases than the simpler XHR. Yes, it is meant for streaming. XMLHttpRequest isn't really. (And EventSource will get CORS in due course.) XHR is a pretty stable and well supported method, it seems that it'd be reasonably straightforward to take the current good-will around that standard, and see if a second ArrayBuffer response type is warranted. I rather wait until all the new features are more widely adopted and tested. Then we can see if they have been a success and if we need more. One nice thing to come out of it, saving a large file to a disk via XHR and FileWriter would be made much easier, with no need for temporary storage locations. Even with blob saved to disk, it'd take a lot of special case optimizations to make it efficient to copy that Blob to a new file. It'd likely require a copy, instead of what's likely wanted: writing the file once. Developing this now could have a positive effect on a future EventSource standard. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] open method extension for TLS authentication
On Thu, 03 Feb 2011 17:42:34 +0100, Tim tim-resea...@sentinelchicken.org wrote: Anne, others, Do you have any opinions on this? There have recently been some good discussions around HTTP authentication on IETF mailing lists, and I think having some flexibility here would be useful in the long run. I do not really have an opinion, sorry. If you want to add new features to the web platform this FAQ entry does describe some steps you could take: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F Hopefully that helps. Let me know if I can do anything else. Cheers, -- Anne van Kesteren http://annevankesteren.nl/
[Bug 11947] [IndexedDB] Updating object stores with auto increment
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11947 Hans Wennborg h...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Hans Wennborg h...@chromium.org 2011-02-04 10:33:39 UTC --- *** This bug has been marked as a duplicate of bug 11976 *** -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: Quota API to query/request quota for offline storages (e.g. IndexedDB, FileSystem)
On Thu, Feb 3, 2011 at 5:40 PM, Charles Pritchard ch...@visc.us wrote: I rather like the prompt in the new FF builds; it's similar to the prompt on Mobile Safari; when you get into the site, it asks you if you're ok storing data, and it allows you to specify a quota stepping. FF does a great job on applicationCache + quota in that area. The FileSystem API is a tricky thing. indexedDB is more straightforward. Let's take localStorage off the table for quota control: it's set at 5 megs in practice, and it's a very different storage mechanism. In practice, websql, appCache and indexeddb are backed by the public domain sqlite library and they share a quota on implementations. I'd like to discuss FileSystem permissions as a distinct item, as localStorage is distinct. I'd be fine with exempting localStorage from API and just lock it at 5MB. It's tricky anyway since it's a synchronous API. Further, the current limits are not defined in terms of size-on-disk but rather size-of-data. Additionally, at least firefox grants 5MB of storage to localStorage without prompting. The same is not true for any of the other storage APIs that we support, and likely won't be for any future ones we'll support. But I don't see why filesystem should be treated separately? None of the above caveats applies to it. Use case for the quota API: When a user wants to download a large set of data for offline use, Scripting needs permission unlimited space. unlimited is often set at 100 megs. The user has to stick around until their quota is full, if they've set a low quota amount. Scripting should not have to require 100 megs explicitly when a user first lands on a page. The user should only see an increase quota request following an input action (such as clicking a link or button). You're setting a lot of, to me seemingly arbitrary, restrictions here. Why does unlimited equal 100 MB? Why shouldn't the page request quota up front? Why shouldn't the page be allowed to request quota any time it chooses? I also don't see why the scenario is specific to the FileSystem API. The same thing can happen with IndexedDB. Consider for example a webmail application which wants to download a large amount of emails and store locally for offline access. The solution here is for the page to estimate how much space it needs and then request that up front. Be that when the user clicks a sync now button, or as soon as the user arrives at the page. Whatever the page thinks produces the best UI. The user can immediately make a choice to grant the quota and then the page can take its time to download the data. This seems to work as well for filesystem as for indexedDB and app-cache. / Jonas
Re: [widgets] New version of PC Ready for pub
On Feb/3/2011 2:15 PM, ext Marcos Caceres wrote: On 2/3/11 8:08 PM, Arthur Barstow wrote: On Feb/1/2011 1:30 PM, ext Marcos Caceres wrote: I have updated the Wigets PC spec for publication as a LC. This new draft specifies the defaultlocale attribute Is support for this proposed attribute going to be added to the Widget object? (I don't see it mentioned in latest ED of the Widget Interface spec.) No, defaultlocale has no relationship to the API side (assuming that is what you mean). I was trying to determine if you had identified a Use Case for exposing this piece of metadata via the Widget object in the TWI spec (and I see you think no). Anyhow, coming back to the proposal - as I understand it, it would plug an interop hole in the CR where if the UA has no locale set, it is left to the UA (i.e. non-deterministic) as to what - if any - localized data the UA will use. The proposal does indeed make that behavior deterministic but since old UAs would ignore this new attribute, the proposal would break UAs based on the CR. Is this correct? -Art Barstow
Re: [Bug 11948] New: index.openCursor's cursor should have a way to access the index's value (in addition to the index's key and objectStore's value)
On 2/1/2011 11:00 AM, bugzi...@jessica.w3.org wrote: As discussed in the mailing list thread from bug 11257, we should add some way for index.openCursor cursors to access the primary key for the objectStore. .indexValue, .objectStoreKey, or .primaryKey might be good names to use for it. .objectStoreKey seems to be the most clear way to express this to me. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [FileSystem]: URI format, uses
Le 23 janv. 2011 à 18:13, Glenn Maynard a écrit : But that's the point: when you put pictures (or tax forms, or other private files) on a webserver, you have mechanisms for access control. You wouldn't put private files on a publically-accessible webserver; you put them on a password-protected one. In fact many people do without knowing on many current sites. There is a notion of subtle opacity, aka something which is part of the public but more difficult to access. It has its good and bad social impacts. For example, if you have a flickr account, put an image with a limited shared context. Now find the exact URI of the image. It should be starting with static.flickr.com. Unlog, put this URI into your browser and you should be able to access the image. -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
Re: [Bug 11948] New: index.openCursor's cursor should have a way to access the index's value (in addition to the index's key and objectStore's value)
On Fri, Feb 4, 2011 at 11:14 AM, Shawn Wilsher sdwi...@mozilla.com wrote: On 2/1/2011 11:00 AM, bugzi...@jessica.w3.org wrote: As discussed in the mailing list thread from bug 11257, we should add some way for index.openCursor cursors to access the primary key for the objectStore. .indexValue, .objectStoreKey, or .primaryKey might be good names to use for it. .objectStoreKey seems to be the most clear way to express this to me. Oh, I missed that the original bug included a few suggestions. Given that both me and Jeremy independently thought of indexValue and primaryKey I think that's a decent sign that they are intuitive names. I happen to like primaryKey the most as it's really a key rather than a value that we've got here. For some reason objectStoreKey makes me think that it's connected to the objectStore rather than the entry in it. / Jonas
Re: Quota API to query/request quota for offline storages (e.g. IndexedDB, FileSystem)
On Fri, Feb 4, 2011 at 12:07 AM, Kinuko Yasuda kin...@chromium.org wrote: If we want to make the quota API treat each API differently this would make a lot sense, but I'm not fully convinced by the idea. Putting aside the localStorage for now, do you still see significant issues in having a sshared single quota? Also let me note that this API does not and should not guarantee that the app can actually *write* that amount of data into the storage, even after the quota is granted, and the UA could still stop an API to write further even if it's within the quota. I suppose that even the 2-3x difference--requesting 256 MB and actually getting 512 MB over different APIs--is acceptable, since to users, requesting storage is an order-of-magnitude question more than a precise number. As long as implementations are still allowed to implement separate quotas if they want, it's probably acceptable for this API to not reflect them precisely and to be biased towards a shared quota. 2011/2/4 Ian Fette (イアンフェッティ) ife...@google.com For instance, if a user has been using a site for months, uses it frequently, and the site hits its 5GB limit but there's still 300GB free on the drive, perhaps we just give the site another 5GB and give the user a passive indication that we've done so, and let them do something if they actually care. That's interesting; reducing the amount users are nagged about things that they probably don't care about is important. It would also need to suppress prompting from calls to requestQuota if the quota increase would have been allowed automatically. -- Glenn Maynard
Re: [Bug 11948] New: index.openCursor's cursor should have a way to access the index's value (in addition to the index's key and objectStore's value)
We haven't used the term primary key too much in the spec, but I think a lot might actually be more clear if we used it more. And I think it'd also make a good name here. So I'm OK with that being the name we choose. Here's another question: what do we set primaryKey to for cursors opened via index.openKeyCursor and objectStore.openCursor? It seems as though setting them to null/undefined could be confusing. One possibility is to have .value and .primaryKey be the same thing for the former and .key and .primaryKey be the same for the latter, but that too could be confusing. (I think we have this problem no matter what we name it, but if there were some name that was more clear in these contexts, then that'd be a good reason to consider it instead.) J For objectStore.openCursor, if we went with primaryKey, then would we set both key and primaryKey to be the same thing? Leaving it undefined/null seems odd. On Fri, Feb 4, 2011 at 1:36 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Feb 4, 2011 at 11:14 AM, Shawn Wilsher sdwi...@mozilla.com wrote: On 2/1/2011 11:00 AM, bugzi...@jessica.w3.org wrote: As discussed in the mailing list thread from bug 11257, we should add some way for index.openCursor cursors to access the primary key for the objectStore. .indexValue, .objectStoreKey, or .primaryKey might be good names to use for it. .objectStoreKey seems to be the most clear way to express this to me. Oh, I missed that the original bug included a few suggestions. Given that both me and Jeremy independently thought of indexValue and primaryKey I think that's a decent sign that they are intuitive names. I happen to like primaryKey the most as it's really a key rather than a value that we've got here. For some reason objectStoreKey makes me think that it's connected to the objectStore rather than the entry in it. / Jonas
Re: Quota API to query/request quota for offline storages (e.g. IndexedDB, FileSystem)
On 2/4/2011 1:30 AM, Jonas Sicking wrote: On Thu, Feb 3, 2011 at 5:40 PM, Charles Pritchardch...@visc.us wrote: The FileSystem API is a tricky thing. indexedDB is more straightforward. I'd be fine with exempting localStorage from API and just lock it at 5MB. It's tricky anyway since it's a synchronous API. Further, the ... But I don't see why filesystem should be treated separately? None of the above caveats applies to it. My concern with filesystem is that it's more of an OS-level service than a UA-level service. Other applications, outside of the UA, may interact with the files contained on the FS. At some point, I think this would be a good thing. I know that mount points have been brought up before. I'm just concerned that FS is not yet well defined, whereas idb is self-contained. Use case for the quota API: When a user wants to download a large set of data for offline use, Scripting needs permission unlimited space. unlimited is often set at 100 megs. The user has to stick around until their quota is full, if they've set a low quota amount. Scripting should not have to require 100 megs explicitly when a user first lands on a page. The user should only see an increase quota request following an input action (such as clicking a link or button). You're setting a lot of, to me seemingly arbitrary, restrictions here. Why does unlimited equal 100 MB? Why shouldn't the page request quota up front? Why shouldn't the page be allowed to request quota any time it chooses? From what I recall, Chrome had a 100 meg limit, and Safari did as well. I was just noting that unlimited is not unlimited. It's not relevant to the use case. I also don't see why the scenario is specific to the FileSystem API. The same thing can happen with IndexedDB. Consider for example a webmail application which wants to download a large amount of emails and store locally for offline access. I intended it to address the Quota API we're discussing, not the storage mechanism. The solution here is for the page to estimate how much space it needs and then request that up front. Be that when the user clicks a sync now button, or as soon as the user arrives at the page. Whatever the page thinks produces the best UI. The user can immediately make a choice to grant the quota and then the page can take its time to download the data. This seems to work as well for filesystem as for indexedDB and app-cache. That's what I think, too: when the user clicks a button. I don't like seeing a pop-up when I first load the page. There's about a 5Megs taken-for-granted with localStorage; I wouldn't mind if another 5 megs without prompt were granted for other services, bringing the total untrusted space to 10 megs.
Re: [Bug 11948] New: index.openCursor's cursor should have a way to access the index's value (in addition to the index's key and objectStore's value)
On Fri, Feb 4, 2011 at 3:30 PM, Jeremy Orlow jor...@chromium.org wrote: We haven't used the term primary key too much in the spec, but I think a lot might actually be more clear if we used it more. And I think it'd also make a good name here. So I'm OK with that being the name we choose. Here's another question: what do we set primaryKey to for cursors opened via index.openKeyCursor and objectStore.openCursor? It seems as though setting them to null/undefined could be confusing. One possibility is to have .value and .primaryKey be the same thing for the former and .key and .primaryKey be the same for the latter, but that too could be confusing. (I think we have this problem no matter what we name it, but if there were some name that was more clear in these contexts, then that'd be a good reason to consider it instead.) J For objectStore.openCursor, if we went with primaryKey, then would we set both key and primaryKey to be the same thing? Leaving it undefined/null seems odd. I've been pondering the same questions but so far no answer seems obviously best. One way to think about it is that it's good if you can use the same code to iterate over an index cursor as a objectStore cursor. For example to display a list of results in a table. This would indicate that for objectStore cursors .key and .primaryKey should have the same value. This sort of makes sense too since it means that a objectStore cursor is just a special case of an index cursor where the iterated index just happens to be the primary index. This would leave the index key-cursor. Here it would actually make sense to me to let .key be the index key, .primaryKey be the key in the objectStore, and .value be empty. This means that index cursors and index key-cursors work the same, with just .value being empty for the latter. So in summary objectStore.openCursor: .key = entry key .primaryKey = entry key .value = entry value index.openCursor: .key = index key .primaryKey = entry key .value = entry value index.openKeyCursor: .key = index key .primaryKey = entry key .value = undefined There are two bad things with this: 1. for an objectStore cursor .key and .primaryKey are the same. This does seem unneccesary, but I doubt it'll be a source of bugs or require people to write more code. I'm less worried about confusion since both properties are in fact keys. 2. You can't use the same code to iterate over a key-cursor and a normal cursor and display the result in a table. However I suspect that in most cases key cursors will be used for different things, such as joins, rather than reusing code that would normally use values. I don't feel super strongly on this though. / Jonas
