Re: [whatwg] Effect of image-orientation on naturalWidth/Height
On Fri, 13 Mar 2015 07:39:07 +0100, Philip Jägenstedt phil...@opera.com wrote: For video the rotation is applied to videoWidth and videoHeight, at least in Chromium/Blink. A video with rotation metadata is thus indistinguishable from one where the frame themselves are rotated. If there's any hope that doing the same for img could be Web compatible, and Safari's behavior makes that seem likely, that seems like a pretty good outcome. Let's try it. https://code.google.com/p/chromium/issues/detail?id=413272#c6 -- Simon Pieters Opera Software
Re: [whatwg] Persistent and temporary storage
On 13/03/2015 21:39 , Nils Dagsson Moskopp wrote:
There exists also an issue of perverse incentives. If the browser
tells an application how much storage it can use, an application
developer is likely to try to use the maximum allowed space.
Sorry but I don't think this makes much sense. I can't think of a
developer ever writing code along the lines of:
if (device.hasLeftOverQuota()) {
// ooh! let's write us some more bytes to disk!
}
else {
// oh well, who needz this? LOL!
}
Quotas are useful to set user expectations. For instance, people who
create sites for periodicals are really interested in allowing their
users to download entire issues offline. It's very helpful if they can
say you've got enough space for 3 more issues or you're short on
space, do you want to remove some older issues.
This could also lead to web apps refusing to run if an user agent
does not report enough space.
Which is completely acceptable. If your app needs to store a large data
set locally, telling the user it won't work upfront is a much better
experience than letting them waste both time and data usage (which can
easily matter a fair bit on mobile) only to fail anyway.
--
Robin Berjon - http://berjon.com/ - @robinberjon
Re: [whatwg] Persistent and temporary storage
On Mon, Mar 16, 2015 at 1:38 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Mar 13, 2015 at 5:06 PM, Joshua Bell jsb...@chromium.org wrote: A handful of us working on Chrome have been having similar discussions around what we've been calling durable storage. In its simplest model a bit granted by the user to an origin, which then requires explicit user action before the data might be cleared under storage pressure, so it sounds like our thinking is broadly aligned, although we're still exploring various possibilities and their implications for permission prompts, cleanup UI, behavior under pressure, etc. Yeah, same here, wiki page outlines a tentative plan. Gotcha. And thanks again for opening up this discussion! Similarly, we've been trying to keep this orthogonal from quota (either the UA's logic for assigning a quota to an origin quota, or possible standardized quota APIs), although the UA may use similar signals for granting permissions/assigning quota. I think we've come around in that we need to expose quota in some way to give developers some expectations to how much they can fetch and then store in best effort mode. I think that matches our latest discussions too... But that for persistent it can be the whole disk. ... and we're waffling on that one. Going that far implies that the UA does a really good job on its own or with user interaction to respond when the storage is indeed getting full. Mobile OSes typically provide UI to inspect how much storage is in use and clear apps and/or portions of their storage. IMHO, we need to fully develop that UX in the UA before I'd be comfortable letting sites easily consume the whole disk. But we realize that artificially capping disk usage is a gap between web and native, and so solving that problem is high priority for us. And I don't think there are spec/standards implications here so we can move fast on the UA side, as long as we spec that QuotaExceededError can happen on various operations regardless of permissions, because even unlimited quota can be constrained by physical limits. (FYI, we've been using durable and non-durable to distance the discussion from the now-loaded temporary vs. persistent terms which surfaced in earlier API proposals, some of which are implemented in Chrome) Ah right. Current set of terms I have is best effort (default; fixed quota), persistent (requires some kind of user opt-in, probably through an API-triggered dialog, but maybe also done if you pin a tab or bookmark or some such; 'unlimited' quota), and temporary (exists outside of best effort/persistent, e.g. for storing social network resources, other volatile assets, requires some kind of API opt-in; fixed quota). If I'm reading the wiki page correctly, I'm intrigued by the temporary proposal. To confirm, you're envisioning a completely new lightweight storage API and there's no implied addition to the other storage APIs? If so... well, pros and cons. I'm not a huge fan of adding Yet Another Storage API. On the other hand, I'd rather do that then fork the existing storage APIs into temp/persistent and try and shoehorn priorities into those. If it helps I did a thought experiment a while ago on what would a stripped-down, Promise-based IDB-lite look like? at https://gist.github.com/inexorabletash/c8069c042b734519680c - it doesn't have the priority scheme, but that would be easy to add at the 'open' entry point. ... One thing we should discuss under the storage umbrella is how atomically we treat all storage for an origin. Customers we've talked to acknowledge the reality that even durable storage can be wiped in the face of user action (e.g. via settings UI to clear cookies etc) or file corruption. One of the situations they're concerned about is dealing with partial clearing of data, e.g. Indexed DB databases are present but the SW cache has been wiped, or vice versa. Currently, for quota-based storage eviction, we evict an origin's entire storage at once - that's easiest for sites to reason about, since it matches the first time user or returning user on new device scenarios that must already be supported. If we're taking a step back to think of storage as a whole, we may want to provide more spec-level assurance in this area. -- https://annevankesteren.nl/
Re: [whatwg] Persistent and temporary storage
On Mon, Mar 16, 2015 at 5:23 PM, Joshua Bell jsb...@chromium.org wrote: On Mon, Mar 16, 2015 at 1:38 AM, Anne van Kesteren ann...@annevk.nl wrote: But that for persistent it can be the whole disk. ... and we're waffling on that one. Going that far implies that the UA does a really good job on its own or with user interaction to respond when the storage is indeed getting full. Mobile OSes typically provide UI to inspect how much storage is in use and clear apps and/or portions of their storage. IMHO, we need to fully develop that UX in the UA before I'd be comfortable letting sites easily consume the whole disk. Yeah, getting better UX/UI is a prerequisite for us as well. Firefox has a page about:permissions today. Something like that, but more easily accessible and without its issues would go some way towards addressing this. And perhaps making sure the user discovers it when they are about to run out of disk space... If I'm reading the wiki page correctly, I'm intrigued by the temporary proposal. To confirm, you're envisioning a completely new lightweight storage API and there's no implied addition to the other storage APIs? If so... well, pros and cons. I'm not a huge fan of adding Yet Another Storage API. On the other hand, I'd rather do that then fork the existing storage APIs into temp/persistent and try and shoehorn priorities into those. I think that's really v2 material anyway. Another idea we had is having named storage areas and then assigning priorities to those, with initially the whole site being in a single area. If it helps I did a thought experiment a while ago on what would a stripped-down, Promise-based IDB-lite look like? at https://gist.github.com/inexorabletash/c8069c042b734519680c - it doesn't have the priority scheme, but that would be easy to add at the 'open' entry point. Yeah, this is also something that warrants more discussion. There's cookies, localStorage, indexed DB, various filesystem APIs, notifications API, history API, and indeed always the question whether we want a nicer indexed DB / asynchronous localStorage. Also seems like v2 material. Something we should consider after bridging the persistence gap. One thing we should discuss under the storage umbrella is how atomically we treat all storage for an origin. Customers we've talked to acknowledge the reality that even durable storage can be wiped in the face of user action (e.g. via settings UI to clear cookies etc) or file corruption. One of the situations they're concerned about is dealing with partial clearing of data, e.g. Indexed DB databases are present but the SW cache has been wiped, or vice versa. Currently, for quota-based storage eviction, we evict an origin's entire storage at once - that's easiest for sites to reason about, since it matches the first time user or returning user on new device scenarios that must already be supported. If we're taking a step back to think of storage as a whole, we may want to provide more spec-level assurance in this area. Yeah, I think until we'd introduce something like named storage areas or temporary storage APIs we should treat everything under the best-effort / persistent banner as atomic. We should probably define that in the specification that outlines this storage architecture and then the various storage APIs we have can tie into it. -- https://annevankesteren.nl/
Re: [whatwg] Persistent and temporary storage
On Fri, Mar 13, 2015 at 3:25 PM, Janusz Majnert j.majn...@samsung.com wrote: On 13.03.2015 15:01, Anne van Kesteren wrote: The reason developers want it is to know how much they can download and store without getting an exception. Which still doesn't guarantee they won't get an exception if the device runs out of space for whatever reason. That is true, it would be an estimate (and I think we should name it as such in the API). With deduplication and compression it can't be super accurate. It's still better to reason with an estimate than with nothing at all though, I think. -- https://annevankesteren.nl/
Re: [whatwg] Persistent and temporary storage
On Fri, Mar 13, 2015 at 5:06 PM, Joshua Bell jsb...@chromium.org wrote: A handful of us working on Chrome have been having similar discussions around what we've been calling durable storage. In its simplest model a bit granted by the user to an origin, which then requires explicit user action before the data might be cleared under storage pressure, so it sounds like our thinking is broadly aligned, although we're still exploring various possibilities and their implications for permission prompts, cleanup UI, behavior under pressure, etc. Yeah, same here, wiki page outlines a tentative plan. Similarly, we've been trying to keep this orthogonal from quota (either the UA's logic for assigning a quota to an origin quota, or possible standardized quota APIs), although the UA may use similar signals for granting permissions/assigning quota. I think we've come around in that we need to expose quota in some way to give developers some expectations to how much they can fetch and then store in best effort mode. But that for persistent it can be the whole disk. (FYI, we've been using durable and non-durable to distance the discussion from the now-loaded temporary vs. persistent terms which surfaced in earlier API proposals, some of which are implemented in Chrome) Ah right. Current set of terms I have is best effort (default; fixed quota), persistent (requires some kind of user opt-in, probably through an API-triggered dialog, but maybe also done if you pin a tab or bookmark or some such; 'unlimited' quota), and temporary (exists outside of best effort/persistent, e.g. for storing social network resources, other volatile assets, requires some kind of API opt-in; fixed quota). -- https://annevankesteren.nl/
Re: [whatwg] Persistent and temporary storage
On Mon, Mar 16, 2015 at 4:12 AM, Biju bijumaill...@gmail.com wrote: At present data stored in indexDB is written some where deep in the profile folder, which is difficult to find. I don't think we should expect our users to traverse the directory structure at all. We need to expose UI to manage sites in about:preferences or equivalent. Additionally if we can restrict these kind of file/storage access to just https site (or some sort of signing mechanism for installed app),, it will help reduce annoyance of asking for permission by ever other site we visit. I suspect this will be HTTPS restricted simply because it is about persistence, but soon every site will have easy access to HTTPS. So if indeed all sites end up asking for this we would need to think of a better model, but I doubt that will be the case. -- https://annevankesteren.nl/
