RE: Supporting Portrait-First and Landscape-First devices in HTML5 Device Orientation
On Aug 15, 2013 5:11 PM, "Dhruv Chadha" wrote: > > Tab, > > We sympathize with the goal of creating a simple programming model for developers but we don’t believe that is what is currently specified on the device and screen orientation specs (as we stated in our earlier response to Jonas). Our proposal maps existing native implementations done by iOS, Android, and Windows. These native APIs provide capabilities to discover the native orientation of the device and to remap the coordinate system based on the user selected orientation. > > We believe that mapping the coordinates to the current screen orientation would generate the following issues: > - Changes the design of the API as defined by current draft of the device orientation spec and will break interoperability with current implementations I agree this is a problem. > - If the browser’s orientation is not locked, rotating the device would reset the coordinates back to 0 in the reference axis for each 90 degree rotation since the browser App UI would rotate as well Why is this bad? Maybe I'm not understanding the concern? > - Does not provide flexibility. What happens if the developer is not interested in automatically re-mapping the coordinate system? They wouldn’t have an ability to change this behavior. What are the use cases for wanting to allow the screen to reorient while at the same time not adjusting the coordinate system? Are these use cases more common than the cases where you would want to adjust the coordinate system? A potential solution is to add a separate set of events exactly like the current DeviceOrientation events, but that are relative to the screen orientation rather than the device orientation. Sadly that might be the only way to keep compatibility with existing deployed implementations, while still keeping a decent API. > - the alpha value (+Z) for device orientation should always be aligned to the input from the compass (i.e. hardware sensors) unless the developer requests a re-mapping I don't understand this. Could you provide an example or describe in more detail? / Jonas
RE: Supporting Portrait-First and Landscape-First devices in HTML5 Device Orientation
On Aug 15, 2013 2:52 PM, "Dhruv Chadha" wrote: > If anything the Device Orientation spec says: the device coordinate frame (i.e. x,y,z) is defined relative to the screen (i.e. hardware screen [2]) in its standard orientation. The hardware sensors that provide device orientation data are aligned to the native/standard orientation. Therefore, for device orientation usage, the current screen orientation (e.g. Landscape-Secondary, Portrait-Primary, etc.) does not determine what is up. This is determined by the hardware. The spec would have to be changed if we want to have the current screen orientation automatically influence what is up. Indeed. I noticed this part of the DeviceOrientation spec after sending my previous email. I think we need to fix this by changing the defined behavior of the specs here. What is currently defined by the DeviceOrientation spec does not seem useful. / Jonas
Re: Supporting Portrait-First and Landscape-First devices in HTML5 Device Orientation
On Thu, Aug 15, 2013 at 5:11 PM, Dhruv Chadha wrote: > We sympathize with the goal of creating a simple programming model for > developers but we don’t believe that is what is currently specified on the > device and screen orientation specs (as we stated in our earlier response to > Jonas). Our proposal maps existing native implementations done by iOS, > Android, and Windows. These native APIs provide capabilities to discover the > native orientation of the device and to remap the coordinate system based on > the user selected orientation. > > We believe that mapping the coordinates to the current screen orientation > would generate the following issues: > - Changes the design of the API as defined by current draft of the device > orientation spec and will break interoperability with current implementations This is a potential problem with any change ever, yes. Do you have reason to believe it will actually be a problem here? That is, do you have any reason to believe there is currently content depending on the device orientation not auto-rotating to be relative to the screen orientation? > - If the browser’s orientation is not locked, rotating the device would reset > the coordinates back to 0 in the reference axis for each 90 degree rotation > since the browser App UI would rotate as well Yes, that's the point. You want to get the same device orientation values whether you're holding the device in portrait or landscape (assuming the page allows rotation). > - Does not provide flexibility. What happens if the developer is not > interested in automatically re-mapping the coordinate system? They wouldn’t > have an ability to change this behavior. Yes, they do, as I mentioned in a side comment in my previous email. The device orientation would only rotate to remain consistent *with the screen orientation*. If you lock the screen orientation (there are existing methods to do so), then the device orientation wouldn't rotate either. That's intended, useful behavior. > In addition, changing the reference coordinate without providing the > actual/native coordinate system will have the following impact: > - the alpha value (+Z) for device orientation should always be aligned to the > input from the compass (i.e. hardware sensors) unless the developer requests > a re-mapping I don't understand what you mean here. This seems to be *exactly the case you're worried about*, where the alpha may be oriented "wrong" because the device is being held in the non-native orientation. It shouldn't matter whether I'm using a webapp displaying a compass with my phone in portrait or landscape orientation - both of them should display the compass pointing north when the "device" (that is, the top of my screen *in my current orientation*) is pointing north. ~TJ
RE: Supporting Portrait-First and Landscape-First devices in HTML5 Device Orientation
Tab, We sympathize with the goal of creating a simple programming model for developers but we don’t believe that is what is currently specified on the device and screen orientation specs (as we stated in our earlier response to Jonas). Our proposal maps existing native implementations done by iOS, Android, and Windows. These native APIs provide capabilities to discover the native orientation of the device and to remap the coordinate system based on the user selected orientation. We believe that mapping the coordinates to the current screen orientation would generate the following issues: - Changes the design of the API as defined by current draft of the device orientation spec and will break interoperability with current implementations - If the browser’s orientation is not locked, rotating the device would reset the coordinates back to 0 in the reference axis for each 90 degree rotation since the browser App UI would rotate as well - Does not provide flexibility. What happens if the developer is not interested in automatically re-mapping the coordinate system? They wouldn’t have an ability to change this behavior. In addition, changing the reference coordinate without providing the actual/native coordinate system will have the following impact: - the alpha value (+Z) for device orientation should always be aligned to the input from the compass (i.e. hardware sensors) unless the developer requests a re-mapping Thanks, Dhruv On Thursday, August 15, 2013 3:09 PM, Tab Atkins Jr. [mailto:jackalm...@gmail.com] > Consolidating email threads from Jonas and Tab: > > In response to Tab's comments: > > I think there is a slight miss-understanding of the issue that we are trying > to address. It seems to me that you are referring to how a developer can know > whether the user is currently holding the device in portrait vs landscape > mode. > > We are trying to address the issue where a developer does not know which > orientation aligns to the Y axis for device orientation. The height and width > do not help in this context. The Y axis is always pointing to the top of the > native orientation of the device. > > With your approach, a developer wouldn't be able to tell if a portrait device > is held in the expected landscape position to play the game. In other words, > the user can held their Portrait device in landscape primary or secondary > modes which wouldn't provide any guidance on how to map coordinates. That is > the reason we believe that we need to provide a mechanism to retrieve the > native or default orientation of the device to provide the frame of reference > needed for the mapping [1]. Ah, I did misunderstand - all the talk about "portrait" and "landscape" made me think that you were talking about Screen Orientation, not Device Orientation. In that case, Jonas is right - if the device is rotated such that Screen Orientation would change its value, the reported values from Device Orientation should change as well. That way authors don't have to do any additional work - the coordinates are always correct and pointing in the "right" direction. (This will also automatically pay attention to things like @viewport locking the orientation - Screen Orientation *shouldn't* change the value then, so you'll continue to get coordinates relative to the original direction even if the device is rotated.) ~TJ
Re: Supporting Portrait-First and Landscape-First devices in HTML5 Device Orientation
On Thu, Aug 15, 2013 at 2:52 PM, Dhruv Chadha wrote: > Consolidating email threads from Jonas and Tab: > > In response to Tab's comments: > > I think there is a slight miss-understanding of the issue that we are trying > to address. It seems to me that you are referring to how a developer can know > whether the user is currently holding the device in portrait vs landscape > mode. > > We are trying to address the issue where a developer does not know which > orientation aligns to the Y axis for device orientation. The height and width > do not help in this context. The Y axis is always pointing to the top of the > native orientation of the device. > > With your approach, a developer wouldn't be able to tell if a portrait device > is held in the expected landscape position to play the game. In other words, > the user can held their Portrait device in landscape primary or secondary > modes which wouldn't provide any guidance on how to map coordinates. That is > the reason we believe that we need to provide a mechanism to retrieve the > native or default orientation of the device to provide the frame of reference > needed for the mapping [1]. Ah, I did misunderstand - all the talk about "portrait" and "landscape" made me think that you were talking about Screen Orientation, not Device Orientation. In that case, Jonas is right - if the device is rotated such that Screen Orientation would change its value, the reported values from Device Orientation should change as well. That way authors don't have to do any additional work - the coordinates are always correct and pointing in the "right" direction. (This will also automatically pay attention to things like @viewport locking the orientation - Screen Orientation *shouldn't* change the value then, so you'll continue to get coordinates relative to the original direction even if the device is rotated.) ~TJ
RE: Supporting Portrait-First and Landscape-First devices in HTML5 Device Orientation
Consolidating email threads from Jonas and Tab:
In response to Tab's comments:
I think there is a slight miss-understanding of the issue that we are trying to
address. It seems to me that you are referring to how a developer can know
whether the user is currently holding the device in portrait vs landscape mode.
We are trying to address the issue where a developer does not know which
orientation aligns to the Y axis for device orientation. The height and width
do not help in this context. The Y axis is always pointing to the top of the
native orientation of the device.
With your approach, a developer wouldn't be able to tell if a portrait device
is held in the expected landscape position to play the game. In other words,
the user can held their Portrait device in landscape primary or secondary modes
which wouldn't provide any guidance on how to map coordinates. That is the
reason we believe that we need to provide a mechanism to retrieve the native or
default orientation of the device to provide the frame of reference needed for
the mapping [1].
In response to Jonas' comments:
Today, we don't believe there exists any dependencies between the Device
Orientation and Screen Orientation specs. In other words, a developer could
use device orientation information without having to set the screen
orientation. If anything the Device Orientation spec says: the device
coordinate frame (i.e. x,y,z) is defined relative to the screen (i.e. hardware
screen [2]) in its standard orientation. The hardware sensors that provide
device orientation data are aligned to the native/standard orientation.
Therefore, for device orientation usage, the current screen orientation (e.g.
Landscape-Secondary, Portrait-Primary, etc.) does not determine what is up.
This is determined by the hardware. The spec would have to be changed if we
want to have the current screen orientation automatically influence what is up.
[1]
http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/att-0296/Remapping_Table.PNG
[2] http://dev.w3.org/geo/api/start.png
Thanks,
Dhruv
-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Thursday, August 15, 2013 11:55 AM
To: Dhruv Chadha
Cc: public-webapps@w3.org
Subject: Re: Supporting Portrait-First and Landscape-First devices in HTML5
Device Orientation
Hi Dhruv,
I think the idea of the Screen orientation spec is that when the screen
reorients, so should the concept of DeviceOrientation-"up".
This means that it's the current screen orientation that determines what is up,
not the hardware-concept of up.
This should take care of a lot of the author complexities, and they can simply
think of portrait vs. landscape as two different screen sizes.
/ Jonas
On Wed, Aug 14, 2013 at 5:22 AM, Dhruv Chadha
wrote:
> Hi All,
>
>
>
> During our implementation of the Device Orientation API we uncovered
> an issue which would could confuse web developers when building apps
> using this API. The issue is caused by devices with different native
> orientations (portrait vs. landscape).
>
>
>
> The problem this creates is the following:
>
>
>
> Imagine a game which requires the user to hold the device in landscape
> orientation (e.g. car game). For a landscape-first devices the device
> height would the Y axis (attachment:
> GamePlay_Landscape_First_Device.PNG). But if the user has a
> portrait-first device, she would have to rotate the device to
> landscape to correctly play the game play. Because the Y axis of the
> portrait-first device is still the device height, the user would
> continue to get the wrong Y axis information after rotating the
> device. At this point, the developer has to re-map the coordinate
> system (Y to X and X to Y) to allow the game's logic to execute correctly
> since the Y axis is always relative to the device's native orientation.
> (attachment:
> GamePlay_Portrait_First_Device.PNG).
>
>
>
> That is the reason we believe it is important for the developer to
> know the device's native orientation so they could map their axis
> respectively. The proposal is to expose this information using a new
> Screen Orientation API and provide the developer with guidance on how
> to re-map the device orientation coordinates if they require to do so
> (attachment:
> Remapping_Table.PNG). Since Screen Orientation has to do with how the
> physical device is being held (portrait or landscape), exposing the
> native orientation made sense under the Screen Orientation API.
>
>
>
> The Interface for Screen Orientation would therefore be as follows:
>
>
>
> partial interface Screen {
>
> ...
>
> readonly attribute DOMString nativeorientation; };
>
>
>
> The meaning and type of this new property would look something like this:
>
>
>
> nativeorientation of type DOMString, readonly
>
>
>
> The user agent MUST return the value representing the native
> orientation of the screen. The returned orientation MUST be in the
> cur
Re: Supporting Portrait-First and Landscape-First devices in HTML5 Device Orientation
Hi Dhruv,
I think the idea of the Screen orientation spec is that when the
screen reorients, so should the concept of DeviceOrientation-"up".
This means that it's the current screen orientation that determines
what is up, not the hardware-concept of up.
This should take care of a lot of the author complexities, and they
can simply think of portrait vs. landscape as two different screen
sizes.
/ Jonas
On Wed, Aug 14, 2013 at 5:22 AM, Dhruv Chadha
wrote:
> Hi All,
>
>
>
> During our implementation of the Device Orientation API we uncovered an
> issue which would could confuse web developers when building apps using this
> API. The issue is caused by devices with different native orientations
> (portrait vs. landscape).
>
>
>
> The problem this creates is the following:
>
>
>
> Imagine a game which requires the user to hold the device in landscape
> orientation (e.g. car game). For a landscape-first devices the device height
> would the Y axis (attachment: GamePlay_Landscape_First_Device.PNG). But if
> the user has a portrait-first device, she would have to rotate the device to
> landscape to correctly play the game play. Because the Y axis of the
> portrait-first device is still the device height, the user would continue to
> get the wrong Y axis information after rotating the device. At this point,
> the developer has to re-map the coordinate system (Y to X and X to Y) to
> allow the game’s logic to execute correctly since the Y axis is always
> relative to the device’s native orientation. (attachment:
> GamePlay_Portrait_First_Device.PNG).
>
>
>
> That is the reason we believe it is important for the developer to know the
> device’s native orientation so they could map their axis respectively. The
> proposal is to expose this information using a new Screen Orientation API
> and provide the developer with guidance on how to re-map the device
> orientation coordinates if they require to do so (attachment:
> Remapping_Table.PNG). Since Screen Orientation has to do with how the
> physical device is being held (portrait or landscape), exposing the native
> orientation made sense under the Screen Orientation API.
>
>
>
> The Interface for Screen Orientation would therefore be as follows:
>
>
>
> partial interface Screen {
>
> ...
>
> readonly attribute DOMString nativeorientation; };
>
>
>
> The meaning and type of this new property would look something like this:
>
>
>
> nativeorientation of type DOMString, readonly
>
>
>
> The user agent MUST return the value representing the native orientation of
> the screen. The returned orientation MUST be in the current orientation
> list.
>
>
>
> The nativeorientation would be populated from the orientation using the
> DisplayProperties.NativeOrientation on Windows devices. On Android devices,
> the NativeOrientation has to be calculated using the Display.getRotation()
> function and comparing it to the current orientation.
>
>
>
> I look forward to your feedback.
>
>
>
> Thanks,
>
> Dhruv Chadha
>
> Program Manager, Core Web Platform
>
> Windows Phone
>
>
Re: Updating Quota API: Promise, Events and some more
On Thu, Aug 15, 2013 at 9:44 AM, Kinuko Yasuda wrote: >> requestQuota for temporary storage: >> I'd like to better understand the use case for requestQuota for temporary >> storage. Are implementations allowed to bring up a prompt when an increased >> temporary storage quota is requested? I thought one of the big use cases for >> temporary storage was that it would never trigger prompts, though obviously >> an exception could be made for the explicit requestQuota function. >> >> If the idea is for it not to bring up a prompt, why would we not simply >> always allocate the largest value that could be requested? >> >> Also, I think that we for temporary storage in Gecko would not want to >> guarantee that the allocated quota (as reported by queryQuota) for temporary >> storage will remain allocated for longer than the running page. I.e. once a >> page is closed, we might want to release the quota allocated and give it to >> another website. > > This is a very good feedback/question. In Chrome we actually don't really > support requestQuota for temporary storage, we just silently ignore the > request but returns the current available quota to the requesting webapp. I > also agree that it won't be desirable to preserve the quota allocated for > temporary storage. > > Seems like having this method take a storage type just confuses > readers/implementors, we should probably just drop the storage type > parameter and rename it to something like 'requestPersistentQuota', or only > add the method to 'navigator.persistentStorage' attribute? I think adding storageQuota.requestPersistentQuota would be a good solution. It seems cleaner than having a separate navigator.persistentStorage object. / Jonas
File* Specifications | Status and some Promises
Greetings WG, There are three moving proposals in the File* arena, and I thought I'd catpure what these are and what the status of these are. 1. The File API, currently updated as editor's draft at http://dev.w3.org/2006/webapi/FileAPI/ Review strongly encouraged :) Notable fixes are: i. A File constructor has been added, which has been a longstanding request. ii. A new static method on URL called URL.createAndRevoke has been added that gets defaults right, and does away with autoRevoke, which nobody implemented for URL.createObjectURL. iii. A Blob URL Store and a Revocation List, useful for URL Fetch (see https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765). This draft should be ready for LC and should be considered the File API v1. 2. Re-writing File APi to be Promises based, which should be considered a v2. The biggest departure from the current state of technology here would really be that we can have Promises right off the Blob itself, which is zeitgeist thinking about these things (and admittedly makes life easier than an XHR-inspired FileReader, which will be made legacy). The best stab at a strawperson was this one by Jonas: http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0727.html But Stream itself temporarily lives here without too much implementation backbone: https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm I think we *should* have a Promises-based File API off of Blob, but I'm not totally sure about the Stream API as it is currently written; I'm amenable to editing the File API v2 portion, modulo our proposal for Stream. 3. Then there's the FileSystem API, currently discussed here: http://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0379.html This was the upshot of discussions on this listserv, as well as internally at Mozilla. I'm amenable to editing this, which is separate but related to 1. and 2. -- A*
Re: Updating Quota API: Promise, Events and some more
Hi Jonas, On Thu, Aug 15, 2013 at 1:20 PM, Jonas Sicking wrote: > Hi Kinuko, > > Very excited to see movement on this API. We are very interested in > implementing this in Gecko once we reach an API that has the right feature > set and polish! The recent changes definitely brings us closer to that > which is great. Definitely looking forward to working with you on this. > It's great to know that Mozilla is interested in this API, and thanks very much for the valuable feedbacks. > I have a few pieces of high-level fedback, before getting into details. > > Persistence type granularity: > First off, I don't think that we in Gecko are interested in adding support > for per-objectStore or per-Entry persistence type. > > For a couple of reasons we want to use separate files for temporary and > persistent storage. This enables us to both measure the amount of > temporary/persistent storage, as well as clear temporary storage, without > doing slow operations involving running transactions or reading a lot of > files. > > Additionally, in our backends we wouldn't have the ability to measure how > much storage a particular objectStore is using. Or to measure how much the > metadata for a particular Entry uses. > > So I'd prefer to only support setting storage type on a per-database and > per-filesystem basis. > > getStorageType/setStorageType: > I'm not convinced that it makes sense to have a cross-storage-API API for > moving data between the different storage types. > > I definitely think that we need to support moving IDB databases or > Filesystems between temporary and permanent storage. In particular moving > data from temporary storage to persistent storage seems very useful. > > But I think this is something that we should do on a per-storage-API > basis. I.e. the API for moving an IDB database should probably be part of > IDB. And moving data between filesystems already exists in both the Google > Filesystem proposal as well as the Mozilla filesystem proposal. > I mostly agree with your points that 1. it's desirable to support moving data across temporary and persistent storage, and 2. it's more natural to support it on a per-storage-API basis. Also regarding the persistence type granularity we (Chrome) are actually in a very similar situation, i.e. it's not very easy to support per-objectStore or per-Entry persistence type. As I wrote in the response to Joshua's feedback the real 'desire' to have this kind of methods is to give more control to webapps on which data to be kept or evicted when the storage is getting tight, and I'm not willing to stick to the current proposal. If each storage API can support the desire of mobile/offline webapps that'd be good enough (if not great). After hearing feedbacks from you and Joshua, and knowing that IDB is going to support storage types in a near future, I feel we can drop these methods from this draft. (I'm also going to reach out the original requester to see if it works for them too) > requestQuota for temporary storage: > I'd like to better understand the use case for requestQuota for temporary > storage. Are implementations allowed to bring up a prompt when an increased > temporary storage quota is requested? I thought one of the big use cases > for temporary storage was that it would never trigger prompts, though > obviously an exception could be made for the explicit requestQuota function. > > If the idea is for it not to bring up a prompt, why would we not simply > always allocate the largest value that could be requested? > > Also, I think that we for temporary storage in Gecko would not want to > guarantee that the allocated quota (as reported by queryQuota) for > temporary storage will remain allocated for longer than the running page. > I.e. once a page is closed, we might want to release the quota allocated > and give it to another website. > This is a very good feedback/question. In Chrome we actually don't really support requestQuota for temporary storage, we just silently ignore the request but returns the current available quota to the requesting webapp. I also agree that it won't be desirable to preserve the quota allocated for temporary storage. Seems like having this method take a storage type just confuses readers/implementors, we should probably just drop the storage type parameter and rename it to something like 'requestPersistentQuota', or only add the method to 'navigator.persistentStorage' attribute? > / Jonas > > On Tue, Aug 13, 2013 at 10:57 PM, Kinuko Yasuda > wrote: > > Hi all, > > > > It's been a while since Quota API's FPWD ( > http://www.w3.org/TR/quota-api/) > > was published and we've gotten several requests/feedbacks so far. > > To address some of the requests and to gain more consensus, I'm thinking > > about making following changes to the Quota API: > > > > * Use Promises rather than callbacks > > * Add Events to notify webapps of important changes in the local storage > > space > > * Establish a way to get and
Re: Updating Quota API: Promise, Events and some more
Hi Joshua,
On Thu, Aug 15, 2013 at 6:33 AM, Joshua Bell wrote:
>
> Promise getStorageType((IDBObjectStore or Database or
>> Entry) object);
>> Promise setStorageType((IDBObjectStore or Database or Entry)
>> object, StorageType type);
>>
>
> For IndexedDB, an object store is (probably) too low a level to specify a
> storage type; ISTM that a database makes more sense as the level of
> granularity for specifying storage, since that avoids the complexity of a
> store disappearing out from within a database. Was the use of object store
> here intentional?
>
> From an API perspective, passing an IDBObjectStore instance also doesn't
> make much sense as that sort of object is really a transaction-specific
> handle. Before delving deeply, my gut reaction is that to fit into this API
> you would need to pass an IDBDatabase connection object, and it would
> generate an error unless called during a versionchange transaction (which
> guarantees there are no other connections).
>
Thanks for the very informative feedback. The use of object store wasn't
really intentional (it was partly due to lack of my understanding), and if
IDBDatabase connection object makes more sense I'm open to making the
change (more discussion follows).
That still feels like an odd mix of two APIs. An approach that we (Moz +
> Google) have talked about would be to extend the IDBFactory.open() call
> with an options dictionary, e.g.
>
> request = indexedDB.open({ name: ..., version: ..., storage: "temporary"
> });
>
Honestly I was debating whether I should add these methods to this
proposal, as I had the same feeling as yours when I heard the original
request, but if IDB is going to have the ability to set storage type at
creation that sounds great, and would make the current situation much
better.
After all what is lacking in the current quota (+idb or other storage API)
world is:
(1) to know which storage type a storage object belongs to (or in other
words how the data stored in idb is going to be managed by UA), and
(2) to adjust the amount of data in each storage type to avoid undesirable
data deletion/eviction by UA.
On a tangent...
>
> An open question is if the storage type (1) can be assigned only when an
> IDB database is created, or (2) can be changed, allowing an IDB database to
> be moved while retaining data, or (3) defines a namespace between origin
> and database, i.e. "example.com" / "permanent" / "db-1" and "example.com"
> / "temporary" / "db-1" co-exist as separate databases.
>
> What are your thoughts on those 3 options with respect to other storage
> systems?
>
If I were to develop a mobile offline app I could live with (1), though I
may not fall into a typical webapp developer category. If the granularity
to set storage type is IDB database (2) does not sound very useful. (3)
sounds interesting and useful, though I'm not sure how much complexity it
would add in the implementation.
> StorageWatcher createStorageWatcher(StorageType type)
>> };
>>
>> This new draft uses string enums to specify storage types rather than
>> separate attributes on navigator (e.g. navigator.temporaryStorage),
>> mainly because some methods (like {get,set}StorageType do not fit well
>> in split interface) and to preserve greater flexibility to add more
>> storage
>> types in a future. I'm open to discussions though.
>>
>> supportedTypes are list of all StorageType's supported by the UA.
>>
>> * queryStorageInfo and requestQuota are Promise version of
>> queryUsageAndQuota and requestQuota, which is for querying the current
>> storage info (usage and quota) and requesting a new quota, respectively.
>> Both return the current (or updated) StorageInfo.
>>
>> * getStorageType and setStorageType are new methods which are intended to
>> work horizontally across multiple storage APIs. getStorageType(object)
>> returns the current storage type for the given storage object, and
>> setStorageType(object, type) changes the object's storage type.
>> They may fail if the storage backend of the object does not support
>> Quota API or does not support getting or setting (changing) storage
>> types.
>>
>> We're aware that this API may not work very well with FileSystem
>> API(s), and
>> also will need coordination with IndexedDB. Feedback is strongly
>> encouraged
>> here.
>>
>>
> Since it doesn't seem like a good fit for FileSystem or (IMHO) IndexedDB,
> can you give an example where this API does make sense? That might help
> inform what the shape of such a horizontal API would be like that would
> work with IDB, etc.
>
Putting aside the API details now (I admit these methods are not in a
really good shape), the real desire behind this request (and another
request to have more granularity in storage types, which is not addressed
in this draft version) is, to allow webapps to specify a part of their data
not to be evicted when the storage pressure is getting high, and the
decision on which data should be kept or ev
[Bug 20887] Add a File constructor
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20887 Arun changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
