[admin] Publishing specs before TPAC: CfC start deadline is Oct 15
The upcoming TPAC meeting week (Oct 29-Nov2) provides an opportunity for joint WG meetings and lots of informal information sharing. As such, it can be useful to make new publications before TPAC. There is a publication blackout period around TPAC and Oct 23 is the last day to request publication before TPAC. Given our 1-week CfC for new publications, weekends, etc., Oct 15 is the last day to start a CfC to publish a document before TPAC. However, a lot of groups publish documents at this time so starting the CfC earlier is highly recommended. Scanning [PubStatus], here are some potential candidates to publish before TPAC. It would be good to re-publish our newer specs, especially if the spec has had some relatively significant changes (since FPWD) and/or it is getting some implementation/deployment: * File API - Arun can you get this spec ready for LC by October 15? * Gamepad - Scott, Ted - what's the status of the spec and its implementation? * Indexed Database API - Jonas, Eliot - what's the status of LC#1 comment processing? Is a new LC going to be necessary? * Pointer Lock - Vincent - what's the status of the spec and its implementation? * Screen Orientation - Mounir - what's the status of the spec and its implementation? * Server-sent Events - Hixie - can you give a rough guestimate on when bugs 15495 and 18796 will be fixed? (It looks to me like those are the only two bugs blocking CR.) If any other Editors want to publish a spec before TPAC, that would be great so please let us know and I'll start a CfC to publish. -Thanks, AB [PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus
Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15
On Wed, Sep 26, 2012 at 7:27 AM, Arthur Barstow art.bars...@nokia.com wrote: The upcoming TPAC meeting week (Oct 29-Nov2) provides an opportunity for joint WG meetings and lots of informal information sharing. As such, it can be useful to make new publications before TPAC. There is a publication blackout period around TPAC and Oct 23 is the last day to request publication before TPAC. Given our 1-week CfC for new publications, weekends, etc., Oct 15 is the last day to start a CfC to publish a document before TPAC. However, a lot of groups publish documents at this time so starting the CfC earlier is highly recommended. Scanning [PubStatus], here are some potential candidates to publish before TPAC. It would be good to re-publish our newer specs, especially if the spec has had some relatively significant changes (since FPWD) and/or it is getting some implementation/deployment: * File API - Arun can you get this spec ready for LC by October 15? * Gamepad - Scott, Ted - what's the status of the spec and its implementation? * Indexed Database API - Jonas, Eliot - what's the status of LC#1 comment processing? Is a new LC going to be necessary? * Pointer Lock - Vincent - what's the status of the spec and its implementation? Firefox 14 and Chrome 22 shipped Pointer Lock implementations to stable channel users recently. (Check out this Mozilla demo https://developer.mozilla.org/en-US/demos/detail/bananabread, using either.) Pointer Lock specification did have minor adjustments (inter-document and iframe sandbox security issues, pending state and mouse movement clarifications). diffs: http://dvcs.w3.org/hg/pointerlock/log/default/index.html So, I'm happy to prepare an updated working draft. * Screen Orientation - Mounir - what's the status of the spec and its implementation? * Server-sent Events - Hixie - can you give a rough guestimate on when bugs 15495 and 18796 will be fixed? (It looks to me like those are the only two bugs blocking CR.) If any other Editors want to publish a spec before TPAC, that would be great so please let us know and I'll start a CfC to publish. -Thanks, AB [PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus
[pointerlock] Is Pointer Lock feature complete i.e. LC ready? [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]
On 9/26/12 11:46 AM, ext Vincent Scheib wrote: On Wed, Sep 26, 2012 at 7:27 AM, Arthur Barstow art.bars...@nokia.com wrote: * Pointer Lock - Vincent - what's the status of the spec and its implementation? Firefox 14 and Chrome 22 shipped Pointer Lock implementations to stable channel users recently. (Check out this Mozilla demo https://developer.mozilla.org/en-US/demos/detail/bananabread, using either.) Pointer Lock specification did have minor adjustments (inter-document and iframe sandbox security issues, pending state and mouse movement clarifications). diffs: http://dvcs.w3.org/hg/pointerlock/log/default/index.html So, I'm happy to prepare an updated working draft. Thanks for the update Vincent! Do you and/or the implementers consider the spec feature complete, which is a major factor to determine if the spec is Last Call ready (other considerations are documented at [1])? (Bugzilla reports Zarro Boogs found [2] and I didn't notice any issue/bug blocks in the latest ED). -Thanks, Art [1] http://www.w3.org/2005/10/Process-20051014/tr.html#last-call [2] https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=Pointer%20Lockresolution=---
RE: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15
Hi Art, We've previously called for any comments to the current Push API draft [1], and would like to promote it to FPWD before TPAC. We haven't received any substantive comments as far as I know, which tells me that it could be in good shape for publication. With the addition of Telefonica (Eduardo) as co-editor and simplification / better alignment with proposals for B2G / Firefox OS, I believe we are in shape for FPWD now. So if I could request a CFC for publication as FPWD before Oct 15, that would be our preference. Alternatively we can put this on the agenda for TPAC and discuss/promote it then as possible. But in the absence of substantive comments (which tells me we have addressed most of the comments on the first ED), I think we should be ready for FPWD. [1] http://dvcs.w3.org/hg/push/raw-file/default/index.html Thanks, Bryan Sullivan -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Wednesday, September 26, 2012 7:27 AM To: public-weba...@w3c.org Subject: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15 The upcoming TPAC meeting week (Oct 29-Nov2) provides an opportunity for joint WG meetings and lots of informal information sharing. As such, it can be useful to make new publications before TPAC. There is a publication blackout period around TPAC and Oct 23 is the last day to request publication before TPAC. Given our 1-week CfC for new publications, weekends, etc., Oct 15 is the last day to start a CfC to publish a document before TPAC. However, a lot of groups publish documents at this time so starting the CfC earlier is highly recommended. Scanning [PubStatus], here are some potential candidates to publish before TPAC. It would be good to re-publish our newer specs, especially if the spec has had some relatively significant changes (since FPWD) and/or it is getting some implementation/deployment: * File API - Arun can you get this spec ready for LC by October 15? * Gamepad - Scott, Ted - what's the status of the spec and its implementation? * Indexed Database API - Jonas, Eliot - what's the status of LC#1 comment processing? Is a new LC going to be necessary? * Pointer Lock - Vincent - what's the status of the spec and its implementation? * Screen Orientation - Mounir - what's the status of the spec and its implementation? * Server-sent Events - Hixie - can you give a rough guestimate on when bugs 15495 and 18796 will be fixed? (It looks to me like those are the only two bugs blocking CR.) If any other Editors want to publish a spec before TPAC, that would be great so please let us know and I'll start a CfC to publish. -Thanks, AB [PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus
[push-api] Moving Push API to FPWD [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]
On 9/26/12 1:49 PM, ext SULLIVAN, BRYAN L wrote: We've previously called for any comments to the current Push API draft [1], and would like to promote it to FPWD before TPAC. We haven't received any substantive comments as far as I know, which tells me that it could be in good shape for publication. With the addition of Telefonica (Eduardo) as co-editor and simplification / better alignment with proposals for B2G / Firefox OS, I believe we are in shape for FPWD now. So if I could request a CFC for publication as FPWD before Oct 15, that would be our preference. Alternatively we can put this on the agenda for TPAC and discuss/promote it then as possible. But in the absence of substantive comments (which tells me we have addressed most of the comments on the first ED), I think we should be ready for FPWD. [1] http://dvcs.w3.org/hg/push/raw-file/default/index.html The requirements for FPWD are relatively loose but because the publication of a FPWD starts a Call for (IP) Exclusions, it is helpful for some reviewers if the breath of the spec is mostly complete, although the depth can certainly be lacking. What is your view on the set of features/scope? Is the ED covering most of the scope? If there are any high priority features missing, what are they? Based on a very quick scan, I noticed: * The Privacy and Security section is empty and I think it would be helpful if some additional informational was added before FPWD. * The Specific Service Bindings section is empty. It seems like this should have some information before FPWD, especially if it is going to be a normative section. (Are some of these bindings specified outside the W3C?) * Push Framework - it appears this section should be marked as non-normative. I think it would be helpful if some type of flow diagram was included as well as example application code to use the API (although this non-normative info is not necessarily a blocker for FPWD). * serverProtocols - what are the expectations for the valid set of values; where are they specified? Some editorial comments ... * Define Web Intent Push Service provider, Push server and webapp or add a link to the definitions. * Update the references that are out of date (e.g. HTML5). * Not clear what onopen event is since it isn't part of the PushService API -Thanks, Art
Re: [pointerlock] Is Pointer Lock feature complete i.e. LC ready? [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]
On Wed, Sep 26, 2012 at 9:17 AM, Arthur Barstow art.bars...@nokia.com wrote: On 9/26/12 11:46 AM, ext Vincent Scheib wrote: On Wed, Sep 26, 2012 at 7:27 AM, Arthur Barstow art.bars...@nokia.com wrote: * Pointer Lock - Vincent - what's the status of the spec and its implementation? Firefox 14 and Chrome 22 shipped Pointer Lock implementations to stable channel users recently. (Check out this Mozilla demo https://developer.mozilla.org/en-US/demos/detail/bananabread, using either.) Pointer Lock specification did have minor adjustments (inter-document and iframe sandbox security issues, pending state and mouse movement clarifications). diffs: http://dvcs.w3.org/hg/pointerlock/log/default/index.html So, I'm happy to prepare an updated working draft. Thanks for the update Vincent! Do you and/or the implementers consider the spec feature complete, which is a major factor to determine if the spec is Last Call ready (other considerations are documented at [1])? There are no known issues, and no known additional features. We haven't seen many applications developed yet, but there have been a few functionally complete demos. Reading over [1] I believe it is Last Call Ready. (Bugzilla reports Zarro Boogs found [2] and I didn't notice any issue/bug blocks in the latest ED). -Thanks, Art [1] http://www.w3.org/2005/10/Process-20051014/tr.html#last-call [2] https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=Pointer%20Lockresolution=---
Re: Sandboxed Filesystem use cases? (was Re: Moving File API: Directories and System API to Note track?)
Asking about use cases that can be served by a filesystem API, but not by IDB, is reasonable [and I'll respond to it below], but it misses a lot of the point. The users I've talked to like the FS API because it's a simple interface that everyone already understands, that's powerful enough to handle a huge variety of use cases. Sure, the async API makes it a bit more complicated. Every API that handles large data is stuck with the same overhead there. But underneath that, people know what to expect from it and can figure it out very quickly. You just need to store 100KB? 1) Request a filesystem. 2) Open a file. 3) Write your data. Need a URL for that? Sure, it's just a file, so obviously that works. Want it organized in directories just like your server or dev environment? Go ahead. You don't have to write SQL queries, learn how to organize data into noSQL tables, or deal with version change transactions. If you want to see what's in your data store, you don't need to write a viewer to dump your tables; you just go to the URL of any directory in your store and browse around. Our URLs have a natural structure that matches the directory tree. If you add URLs to IDB, with its free-form key/value arrangement, I don't forsee an immediate natural mapping that doesn't involve lots of escaping, ugly URLs, and/or limitations. On to the use cases: Things that work well in a sandboxed filesystem that don't work well in IDB [or any of the other current storage APIs] are those that involve nontransactional modifications of large blobs of data. For example, video/photo/audio editing, which involve data that's too big to store lots of extra copies of for rollback of failed transactions, and which you don't necessarily want to try to fit into memory. Overwriting just the ID3 tag of an MP3, or just the comment section of the EXIF in a JPEG, would be much more efficient via a filesystem interface. Larger series of modifications to those files, which you don't want to hold in memory, would be similar. I know Jonas wants to bolt nontransactional data onto the side of IDB via FileHandle, but I think that the cure there is far worse than the disease, and I don't think anyone at Google likes that proposal. I haven't polled everyone, but that's the impression I get. Beyond individual use cases: When looking at use cases for a filesystem API, people often want to separate the sandboxed cases and the non-sandboxed cases [My Photos, etc.]. It's also worthwhile to look at the added value of having a single API that works for both cases. You have a photo organizer that works in the sandbox with downloaded files? If your browser supports external filesystems, you can adapt your code to run in either place with a very small change [mainly dealing with paths that aren't legal on the local system]. If you're using IDB in the sandbox, and have a different API to expose media directories, you've got to start over, and then you have to maintain both systems. One added API? It's pretty clear that people see the value of an API that lets one access My Photos from the web. That API is necessarily going to cope with files and directories on some platforms, even if others don't expose directories as such. If we're going to need to add a filesystem API of some kind to deal with that, also using the same API to manage a sandboxed storage area seems like a very small addition to the web platform, unlike the other storage APIs we've added in the past. Regarding your final note: I'm not sure what you're talking about with BlobBuilder; is that the EXIF overwrite case you're trying to handle? If so, File[Handle|Writer] with BlobBuilder and seek seems to handle it better than anything else. Eric On Tue, Sep 25, 2012 at 11:57 AM, Maciej Stachowiak m...@apple.com wrote: On Sep 25, 2012, at 10:20 AM, James Graham jgra...@opera.com wrote: In addition, this would be the fourth storage API that we have tried to introduce to the platform in 5 years (localStorage, WebSQL, IndexedDB being the other three), and the fifth in total. Of the four APIs excluding this one, one has failed over interoperability concerns (WebSQL), one has significant performance issues and is discouraged from production use (localStorage) and one suffers from a significant problems due to its legacy design (cookies). The remaining API (IndexedDB) has not yet achieved widespread use. It seems to me that we don't have a great track record in this area, and rushing to add yet another API probably isn't wise. I would rather see JS-level implementations of a filesystem-like API on top of IndexedDB in order to work out the kinks without creating a legacy that has to be maintained for back-compat than native implementations at this time. I share your concerns about adding yet-another-storage API. (Although I believe there are major websites that have adopted or are in the process of adopting IndexedDB). I like my
RE: [push-api] Moving Push API to FPWD [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]
Thanks for the feedback, Art. I've responded below. I will work on a new draft to address as many of your comments as I can. Thanks, Bryan Sullivan | Service Standards | ATT +1-425-580-6514 -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Wednesday, September 26, 2012 11:59 AM To: SULLIVAN, BRYAN L Cc: public-weba...@w3c.org Subject: [push-api] Moving Push API to FPWD [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15] On 9/26/12 1:49 PM, ext SULLIVAN, BRYAN L wrote: We've previously called for any comments to the current Push API draft [1], and would like to promote it to FPWD before TPAC. We haven't received any substantive comments as far as I know, which tells me that it could be in good shape for publication. With the addition of Telefonica (Eduardo) as co-editor and simplification / better alignment with proposals for B2G / Firefox OS, I believe we are in shape for FPWD now. So if I could request a CFC for publication as FPWD before Oct 15, that would be our preference. Alternatively we can put this on the agenda for TPAC and discuss/promote it then as possible. But in the absence of substantive comments (which tells me we have addressed most of the comments on the first ED), I think we should be ready for FPWD. [1] http://dvcs.w3.org/hg/push/raw-file/default/index.html The requirements for FPWD are relatively loose but because the publication of a FPWD starts a Call for (IP) Exclusions, it is helpful for some reviewers if the breath of the spec is mostly complete, although the depth can certainly be lacking. What is your view on the set of features/scope? Is the ED covering most of the scope? If there are any high priority features missing, what are they? IMO the ED is covering the scope well. I don't think any high priority features are missing. We removed some of the earlier proposed features in the current draft. Based on a very quick scan, I noticed: * The Privacy and Security section is empty and I think it would be helpful if some additional informational was added before FPWD. I have some text I can add for that. * The Specific Service Bindings section is empty. It seems like this should have some information before FPWD, especially if it is going to be a normative section. (Are some of these bindings specified outside the W3C?) I think this was intended to be an informative section, unless at least one push service is proposed to be standardized. I can provide informative text for SMS, SIP, and OMA Push. Browser-specific push serices could also be included. * Push Framework - it appears this section should be marked as non-normative. I think it would be helpful if some type of flow diagram was included as well as example application code to use the API (although this non-normative info is not necessarily a blocker for FPWD). Agreed, this should be informative. * serverProtocols - what are the expectations for the valid set of values; where are they specified? Good question. We need some means of registration of well-known services so the protocols can be recognized. Some editorial comments ... * Define Web Intent Push Service provider, Push server and webapp or add a link to the definitions. Will do. * Update the references that are out of date (e.g. HTML5). Will do. This is respec.js magic. * Not clear what onopen event is since it isn't part of the PushService API I think this may have been an omission, or we were thinking to use a listener for changes to the readyState as the open event. I will check with Eduardo on that. -Thanks, Art
