Re: [streams-api] Seeking status of the Streams API spec
On 10/14/14 11:06 PM, Takeshi Yoshino wrote: Not to confuse people, too late but I replaced the W3C Streams API spec WD with a pointer to the WHATWG Streams spec and a few sections discussing what we should add to the spec for browser use cases. Takeshi - given the magnitude of the changes in [changeset], a new WD should be published. I'll start a related PSA targeting a publication on October 23. (I'll start working on the draft WD if you don't have the time.) -Thanks, AB [changeset] https://dvcs.w3.org/hg/streams-api/rev/e5b689ded0d6
PSA: publish a new WD of Streams API on October 23
The Streams API spec has significant changes since its last TR publication (November 2013). As such, this is an announcement of an intent to publish a new WD on October 23, using the latest ED as the basis: https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm If anyone has any major concerns this plan, please speak up. -Thanks, AB
Re: PSA: publish a new WD of Streams API on October 23
On Tue, Oct 21, 2014 at 3:58 PM, Arthur Barstow art.bars...@gmail.com wrote: The Streams API spec has significant changes since its last TR publication (November 2013). As such, this is an announcement of an intent to publish a new WD on October 23, using the latest ED as the basis: https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm If anyone has any major concerns this plan, please speak up. I think it would help if a) the Abstract was a bit clearer that the document is just a collection of notes of what we might want to do in the future and b) if the XMLHttpRequest example was removed as it seems unlikely we're actually going to do that at this point. -- https://annevankesteren.nl/
RE: Push API and Service Workers
On 21 Oct 2014 16:53, Shijun Sun shij...@microsoft.com wrote: On Monday, October 20, 2014 9:42 AM, Jake Archibald wrote: Things I guess you'd do as a result of a push message: One of the most typical scenarios is * show a toast notification (e.g. for a new email) * user chooses to dismiss the notification, so not to read the email right away That is it. From the power efficiency perspective, the browser itself doesn't have to always wake up to process the push message. It should be a decision by web developers whether the message should be handled explicitly by the service worker every time it arrives. To reiterate from my previous message: Updating caches should be common, and it's something most native apps get very wrong. Take Twitter for example, I can tap a notification that shows a partial tweet, but I have poor/no connectivity so the full tweet doesn't load. The notification is now gone, so I'm left with less information than I had before I tapped the notification. Twitter should download and cache the full tweet before showing the notification. Taking the email example specifically, the gmail app does the right thing. Not only do you get a notification, but the email is also cached for offline viewing so tapping the notification works regardless of connectivity at moment of tapping. This is exactly the wrong time to guess what high-level things developers want to do and build APIs to do those imagined things.
Push API - PushRegistration and lifetime
Folks, I'm looking for help to a couple more questions on the Push API. 1. What is the typical lifetime expected for a PushRegistration? 2. IF a PushRegistration can expire, what would be the right option(s) to renew the push service? All the Best, Shijun
FileSystem API Comments
Hello, I'm with the IE Platform team at Microsoft. We have a few comments on the latest editor's draft of the newly proposed FileSystem API [1]. 1.1 Use cases (3. Audio/Photo editor with offline access or local cache for speed) * Edited files should be accessible by other client-side applications - Having the sandboxed file system share its contents between all apps would allow apps to tamper with the files of another app. This could result in corrupted files and perhaps an invalid state for some apps that expect certain contents to exist in a file. This makes us wonder: should we warn users about files that are being opened and written to? If an app is just doing a read, can it open a file or directory without the user's permission, or could this pose a possible issue as well? Also, is the Quota Management API going to be a dependency? It's unclear what we would do with regards to requesting permission to access files. Will this spec be responsible for defining what questions/permission inquiries are presented and when they are presented to the user? For example, what happens when one file is locked for use by a different application? Is the user notified and given the option to open a read-only copy of that file? 3. The Directory Interface * Change events - I would like to revisit the discussion on apps getting notifications of changes to files/directories. There are many scenarios where an application would want to react to renames/moves of a file/directory. There would also be value in being notified of a change to a directory's structure. If an app has a file browser that allows a user to select files and/or directories and another app makes changes to the sandboxed filesystem, then it would be expected that the first app should be notified and would be able to refresh its directory tree. Otherwise it would require the user to somehow force a refresh which would not be a good user experience since the user would expect the file browser to update on its own. * removeDeep() move() - Do these support links or junctions? If not, what is the expected behavior? * enumerate() - It would be useful to have pre-filtering support for the following: file/directory, ranges, wildcard search. Currently we would be forced to enumerate the entire set and manually filter out the items we want from the result set. - Callers often know exactly whether or not they want to enumerate files or folders. For example, an image upload service may only be interested in the files present in a directory rather than all of its directories. Perhaps it would be useful to have enumerateFiles() and enumerateDirectories() for this purpose? Or we could have another argument for enumerate() that is an enum (directory, file). - Supporting optimized pagination of large directories. We could have arguments for a starting index and length we would be able to specify a range of items to retrieve within the result set. - Supporting the wildcard character to pre-filter a list of files/directories (e.g. *.jpg). 4. The FileHandle Interface * FileHandles - Is this basically going to be the first to get the handle gets to use it and all subsequent calls need to wait for the file handle to become available again? Are there more details about the locking model used here? * Auto-closing of FileHandles - This may cause confusion as it does not match the common developer mental model of a file handle which is opened and then available for use until it's closed. Perhaps it would be advantageous to have an explicit close function as part of the FileHandle interface? With the current behavior there can be overhead with the unintended closure of the FileHandle that would require a developer to continuously open/close a FileHandle. The currently defined behavior assumes that a developer is done with all their file manipulations when they have completed a promise chain. However, a developer may want to keep the FileHandle open to be used elsewhere at some other point in time that is not related to the current promise chain. An example of the usefulness of having an explicit close function is if you were to implement a word processor and wanted to lock down the file that it currently has open for the period of its editing. This way you are free to continue operating on that file for the duration that it is open, protecting the file from other processes, and not having to undergo the costly setup and teardown of a file handle. * AbortableProgressPromise - It is not clear how a developer would define the abort callback of an AbortableProgressPromise. It seems that the user agent would be responsible for setting the abort callback since it instantiates and returns the AbortableProgressPromise. 5. The FileHandleWritable Interface * write() flush() - It might be useful to have support for transacted streams where
Re: FileSystem API Comments
On 10/21/14 4:36 PM, Ali Alabbas wrote: Hello, I'm with the IE Platform team at Microsoft. We have a few comments on the latest editor's draft of the newly proposed FileSystem API [1]. I believe [1] is Arun's http://w3c.github.io/filesystem-api/Overview.html. 1.1 Use cases (3. Audio/Photo editor with offline access or local cache for speed) * Edited files should be accessible by other client-side applications - Having the sandboxed file system share its contents between all apps would allow apps to tamper with the files of another app. This could result in corrupted files and perhaps an invalid state for some apps that expect certain contents to exist in a file. This makes us wonder: should we warn users about files that are being opened and written to? If an app is just doing a read, can it open a file or directory without the user's permission, or could this pose a possible issue as well? Also, is the Quota Management API going to be a dependency? It's unclear what we would do with regards to requesting permission to access files. Will this spec be responsible for defining what questions/permission inquiries are presented and when they are presented to the user? For example, what happens when one file is locked for use by a different application? Is the user notified and given the option to open a read-only copy of that file? 3. The Directory Interface * Change events - I would like to revisit the discussion on apps getting notifications of changes to files/directories. There are many scenarios where an application would want to react to renames/moves of a file/directory. There would also be value in being notified of a change to a directory's structure. If an app has a file browser that allows a user to select files and/or directories and another app makes changes to the sandboxed filesystem, then it would be expected that the first app should be notified and would be able to refresh its directory tree. Otherwise it would require the user to somehow force a refresh which would not be a good user experience since the user would expect the file browser to update on its own. * removeDeep() move() - Do these support links or junctions? If not, what is the expected behavior? * enumerate() - It would be useful to have pre-filtering support for the following: file/directory, ranges, wildcard search. Currently we would be forced to enumerate the entire set and manually filter out the items we want from the result set. - Callers often know exactly whether or not they want to enumerate files or folders. For example, an image upload service may only be interested in the files present in a directory rather than all of its directories. Perhaps it would be useful to have enumerateFiles() and enumerateDirectories() for this purpose? Or we could have another argument for enumerate() that is an enum (directory, file). - Supporting optimized pagination of large directories. We could have arguments for a starting index and length we would be able to specify a range of items to retrieve within the result set. - Supporting the wildcard character to pre-filter a list of files/directories (e.g. *.jpg). 4. The FileHandle Interface * FileHandles - Is this basically going to be the first to get the handle gets to use it and all subsequent calls need to wait for the file handle to become available again? Are there more details about the locking model used here? * Auto-closing of FileHandles - This may cause confusion as it does not match the common developer mental model of a file handle which is “opened” and then available for use until it's “closed”. Perhaps it would be advantageous to have an explicit close function as part of the FileHandle interface? With the current behavior there can be overhead with the unintended closure of the FileHandle that would require a developer to continuously open/close a FileHandle. The currently defined behavior assumes that a developer is done with all their file manipulations when they have completed a promise chain. However, a developer may want to keep the FileHandle open to be used elsewhere at some other point in time that is not related to the current promise chain. An example of the usefulness of having an explicit close function is if you were to implement a word processor and wanted to lock down the file that it currently has open for the period of its editing. This way you are free to continue operating on that file for the duration that it is open, protecting the file from other processes, and not having to undergo the costly setup and teardown of a file handle. * AbortableProgressPromise - It is not clear how a developer would define the abort callback of an AbortableProgressPromise. It seems that the user agent would be responsible for setting the abort callback since it instantiates and returns the AbortableProgressPromise. 5. The FileHandleWritable Interface * write() flush()
Re: Push API and Service Workers
On 10/16/14 5:52 PM, Shijun Sun wrote: On Thursday, October 16, 2014 11:46 AM, Martin Thomson wrote If the push message is being used to deliver a call notification, that sort of delay will definitely be noticed. And I'm assuming that you've tested on a high end Nexus or something like that. Add the latencies involved in waking an idle device and that turns into a very long post-dial delay. People abandon calls for that sort of delay. Not saying that you are doing it wrong or anything, but just trying to set the right expectations. The RTC scenario is listed explicitly as one of the use cases in the Push API wiki [1]. I expect there is enough interest in the group. Should we allocate some cycles in TPAC to figure out details of the E2E flow? Re scheduling time at TPAC with non group members and remote participants ... We can accommodate remote participants via the W3C phone conference bridge and we will use the W3C's #webapps IRC channel (see [1]). If we want to take advantage of this opportunity, perhaps you should first flesh out specific issue(s) to discuss, and then try to agree on a time + day slot in advance of the meeting. (Currently, there are quite a few open slots on Oct 27 and 28 [2].) -AB [1] https://www.w3.org/wiki/Webapps/November2014Meeting#Meeting_Logistics [2] https://www.w3.org/wiki/Webapps/November2014Meeting#Agenda_Monday_October_27
RE: Push API and Service Workers
On Tuesday, October 21, 2014 2:27 PM, Arthur Barstow wrote: If we want to take advantage of this opportunity, perhaps you should first flesh out specific issue(s) to discuss, and then try to agree on a time + day slot in advance of the meeting. Thanks Arthur for the suggestion. I think we can take a half hour timeslot to discuss the E2E flow for the RTC scenarios using push messages. The goal is to make sure we understand the steps and options in the whole E2E story. If this is a right topic and there is enough interest in the group, I can set up a Doodle to help us pick the timeslot.
