Re: FileSystem API

2013-08-19 Thread Jonas Sicking 
On Mon, Aug 19, 2013 at 4:44 PM, Eric U  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  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

2013-08-19 Thread Eric U 
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  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*

FileSystem API

2013-08-19 Thread Arun Ranganathan 
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*

[Bug 23004] Drop "toNativeLineEndings" from example

2013-08-19 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23004

Arun  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Arun  ---
Fixed.  Thanks for catching this bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: Updating Quota API: Promise, Events and some more

2013-08-19 Thread Jonas Sicking 
On Mon, Aug 19, 2013 at 9:32 AM, Kinuko Yasuda  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

Re: Updating Quota API: Promise, Events and some more

2013-08-19 Thread Kinuko Yasuda 
On Sat, Aug 17, 2013 at 3:01 AM, Jonas Sicking  wrote:

> On Fri, Aug 16, 2013 at 6:56 AM, Kinuko Yasuda 
> 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.
> > Promise 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.
> > Promise 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
>

[Bug 22998] There is no close function on Blob object in latest chrome browser.

2013-08-19 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22998

Olli Pettay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||b...@pettay.fi
 Resolution|--- |INVALID

--- Comment #1 from Olli Pettay  ---
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.

[Bug 23004] New: Drop "toNativeLineEndings" from example

2013-08-19 Thread bugzilla 
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

(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.