[Bug 23004] New: Drop toNativeLineEndings from example
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23004 Bug ID: 23004 Summary: Drop toNativeLineEndings from example Classification: Unclassified Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: File API Assignee: a...@mozilla.com Reporter: sim...@opera.com QA Contact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org The toNativeLineEndings feature was dropped in http://dev.w3.org/cvsweb/2006/webapi/FileAPI/Overview.html.diff?r1=1.181;r2=1.182;f=h because of http://www.w3.org/mid/CA+c2ei_ZLffRr=T-KWAOSGFqO3avtf=nrVoiini=f168fnm...@mail.gmail.com (I assume), but the spec still has it in an example. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 22998] There is no close function on Blob object in latest chrome browser.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22998 Olli Pettay b...@pettay.fi changed: What|Removed |Added Status|NEW |RESOLVED CC||b...@pettay.fi Resolution|--- |INVALID --- Comment #1 from Olli Pettay b...@pettay.fi --- This is not a bug tracker for implementations, but for specifications. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Updating Quota API: Promise, Events and some more
On Sat, Aug 17, 2013 at 3:01 AM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Aug 16, 2013 at 6:56 AM, Kinuko Yasuda kin...@chromium.org
wrote:
I had a few bike-sheddy comments as well.
Now the new draft looks like:
enum StorageType { temporary, persistent };
partial interface Navigator {
readonly attribute StorageQuota storageQuota;
};
[NoInterfaceObject] interface StorageInfo {
unsigned long long usageInBytes;
unsigned long long quotaInBytes;
};
I think these can be simplified to simply 'usage' and 'quota'. The
fact that it's in bytes doesn't really need to be spelled out in the
property name I think. Feedback that we've gotten from authors is that
they prefer short names.
Ok, I don't have strong opinion on the names. Some developers
seem to prefer clearer names but I think just 'usage' and 'quota'
would work in this case.
[NoInterfaceObject] interface StorageQuota {
readonly attribute StorageType[] supportedTypes;
// Queries the current storage info.
PromiseStorageInfo queryStorageInfo(StorageType type);
I think simply 'getInfo' might be enough here. It should already be
obvious that it's storage-quota related.
Sounds good. Actually I wondered the same.
// Requests a new quota for persistent storage.
PromiseStorageInfo requestPersistentQuota(unsigned long long
newQuotaInBytes);
// Creates a new StorageWatcher object to watch the storage changes.
StorageWatcher createStorageWatcher(StorageType type)
This could probably simply be done using a constructor. I.e.
new StorageWatcher(persistent);
Yup... I once wondered we may not want to expose more
constructors on global namespace, but constructor way
actually makes it simpler.
[NoInterfaceObject] interface createStorageWatcher {
// Fired when when the remaining storage space becomes lower
// than 10% of all available space for the type, or before the quota
backend
// triggers eviction (for temporary case), whichever happens first.
attribute EventHandler onstoragelow;
};
Actually, the other two events made sense to me. Without onstorageok
the page has to poll queryStorageInfo to know when it's out of the
woods.
Actually, *only* having onstoragechange would solve both the use case
of detecting when you are running low on storage, as well as when you
are out of the woods. Especially if we provide both the quota and
the amount of used space in the event.
Right. I think probably we should add either a combination of
storagelow + storageok or storagechange, and the latter would be
more complete (and possibly be simpler).
One concern for adding storagechange event is how frequently
the event is going to be fired. In the former email I tentatively wrote
this to be fired every 1 second at most frequent (or whenever the
storage info is changed), but this may be still too frequent if many
apps are contending to a storage space. Do you have any opinion
or preference on this?
/ Jonas
Re: Updating Quota API: Promise, Events and some more
On Mon, Aug 19, 2013 at 9:32 AM, Kinuko Yasuda kin...@chromium.org wrote:
Actually, *only* having onstoragechange would solve both the use case
of detecting when you are running low on storage, as well as when you
are out of the woods. Especially if we provide both the quota and
the amount of used space in the event.
Right. I think probably we should add either a combination of
storagelow + storageok or storagechange, and the latter would be
more complete (and possibly be simpler).
One concern for adding storagechange event is how frequently
the event is going to be fired. In the former email I tentatively wrote
this to be fired every 1 second at most frequent (or whenever the
storage info is changed), but this may be still too frequent if many
apps are contending to a storage space. Do you have any opinion
or preference on this?
I think firing every second while writes are happening would actually
be ok. Seems like you are spending a lot of battery power anyway at
that point and so an extra callback a second doesn't seem like a huge
deal.
That said, doing it more rarely, like every 5 seconds, sounds ok too.
One solution is to punt the choice to the page. I.e. something like:
[Constructor(StorageType type, unsigned long rate)]
interface StorageWatcher {
readonly attribute StorageType type;
readonly attribute unsigned long rate;
attribute EventHandler onstoragechange;
};
/ Jonas
[Bug 23004] Drop toNativeLineEndings from example
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23004 Arun a...@mozilla.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Arun a...@mozilla.com --- Fixed. Thanks for catching this bug. -- You are receiving this mail because: You are on the CC list for the bug.
FileSystem API
Greetings Eric and WG, The Chair and I were discussing setting up repositories for the specifications discussed here (http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0307.html), notably the FileSystem API and File API v2. Before creating a repository to edit the FileSystem API, we thought we'd check with you about the first proposal, which Chrome implements, and get the Google perspective. You've edited the first FileSystem API proposal, which currently lives here (http://www.w3.org/TR/file-system-api/). Can I create a repository and edit the other proposal for FileSystem API, which currently exists as an email thread (http://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0379.html) ? Just checking to see if there are any objections or concerns that would stop a draft or future WG activity. Of course, technical nits should be heard as well, and can proceed concurrently with a draft :) -- A*
Re: FileSystem API
OK, I just finished making my way through the public-script-coord thread [I'm not on that list, but someone pointed me to it]. I have no official objections to you editing a spec based on Jonas's proposal, but I do have a couple of questions: 1) Why is this on public-script-coord instead of public-webapps? 2) Is any vendor other than Mozilla actually interested in this proposal? When it was brought up on public-webapps, and at the WebApps F2F, it dropped with a resounding thud. Given the standardization failure of the Chrome FileSystem API, this could be a massive waste of time. Or it could just be a way for Mozilla to document its filesystem API, since we've already got documentation of the Chrome API, but then you don't need to drag public-script-coord into that. I may have a few small bits of feedback on the color of the bikeshed, but mostly I'm going to stay out of it, lest I accidentally give the impression that we're going to implement it. As I stated at the F2F, we'll be the last ones to do it, but if 2 major browser vendors ship it first, we'll certainly consider it. On Mon, Aug 19, 2013 at 3:11 PM, Arun Ranganathan a...@mozilla.com wrote: Greetings Eric and WG, The Chair and I were discussing setting up repositories for the specifications discussed here (http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0307.html), notably the FileSystem API and File API v2. Before creating a repository to edit the FileSystem API, we thought we'd check with you about the first proposal, which Chrome implements, and get the Google perspective. You've edited the first FileSystem API proposal, which currently lives here (http://www.w3.org/TR/file-system-api/). Can I create a repository and edit the other proposal for FileSystem API, which currently exists as an email thread (http://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0379.html) ? Just checking to see if there are any objections or concerns that would stop a draft or future WG activity. Of course, technical nits should be heard as well, and can proceed concurrently with a draft :) -- A*
Re: FileSystem API
On Mon, Aug 19, 2013 at 4:44 PM, Eric U er...@google.com wrote: OK, I just finished making my way through the public-script-coord thread [I'm not on that list, but someone pointed me to it]. I have no official objections to you editing a spec based on Jonas's proposal, but I do have a couple of questions: 1) Why is this on public-script-coord instead of public-webapps? I started on public-webapps, but once discussion died out here I also wanted to get input from TC39. Generally we're trying to improve coordination between W3C and TC39 so public-script-coord was set up as an attempt to help that. I'm hoping that we'll run all major API designs past them going forward. Not just file-related things, but any API that we design here and in other WGs. There were so far many more changes based on discussions on this list than discussions on public-script-coord. However public-webapps is still the main list for discussing this API. If any major changes are coming out of the discussion with TC39 the intent is to bring those proposed changes back here. 2) Is any vendor other than Mozilla actually interested in this proposal? When it was brought up on public-webapps, and at the WebApps F2F, it dropped with a resounding thud. I'll let others speak up, but yes, I've heard positive signals from other vendors. If we hadn't I wouldn't have let the discussions go as far as they have. / Jonas On Mon, Aug 19, 2013 at 3:11 PM, Arun Ranganathan a...@mozilla.com wrote: Greetings Eric and WG, The Chair and I were discussing setting up repositories for the specifications discussed here (http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0307.html), notably the FileSystem API and File API v2. Before creating a repository to edit the FileSystem API, we thought we'd check with you about the first proposal, which Chrome implements, and get the Google perspective. You've edited the first FileSystem API proposal, which currently lives here (http://www.w3.org/TR/file-system-api/). Can I create a repository and edit the other proposal for FileSystem API, which currently exists as an email thread (http://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0379.html) ? Just checking to see if there are any objections or concerns that would stop a draft or future WG activity. Of course, technical nits should be heard as well, and can proceed concurrently with a draft :) -- A*
