RE: [push-api] Moving Push API to FPWD [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]

[SULLIVAN, BRYAN L]

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 | AT&T
+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
> 

Re: Sandboxed Filesystem use cases? (was Re: Moving File API: Directories and System API to Note track?)

[Eric U]

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  wrote:
>
> On Sep 25, 2012, at 10:20 AM, James Graham  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 m

Re: [pointerlock] Is Pointer Lock feature complete i.e. LC ready? [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]

[Vincent Scheib]

On Wed, Sep 26, 2012 at 9:17 AM, Arthur Barstow  wrote:
> On 9/26/12 11:46 AM, ext Vincent Scheib wrote:
>>
>> On Wed, Sep 26, 2012 at 7:27 AM, Arthur Barstow 
>> 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] 
> [2]
> 

[push-api] Moving Push API to FPWD [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]

[Arthur Barstow]

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: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15

[SULLIVAN, BRYAN L]

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] 
> 

[pointerlock] Is Pointer Lock feature complete i.e. LC ready? [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]

[Arthur Barstow]

On 9/26/12 11:46 AM, ext Vincent Scheib wrote:

On Wed, Sep 26, 2012 at 7:27 AM, Arthur Barstow  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] 
[2] 
 

Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15

[Vincent Scheib]

On Wed, Sep 26, 2012 at 7:27 AM, Arthur Barstow  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] 
>
>

[admin] Publishing specs before TPAC: CfC start deadline is Oct 15

[Arthur Barstow]

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]