from:"SULLIVAN, BRYAN L"

I agree, Push Message is the term that is used in other standards e.g. OMA 
Push. The use of the term notification was a reflection of the current 
simplified API design which provides only a trigger to the application, as a 
notification that some data is available at the server. As we consider the 
introduction of an optional payload into the API, the term Push Message becomes 
more appropriate.

Thanks,
Bryan Sullivan

On Mar 10, 2014, at 11:23 PM, Jeffrey Yasskin 
jyass...@google.commailto:jyass...@google.com wrote:

The term push notification in
https://dvcs.w3.org/hg/push/raw-file/tip/index.html#dfn-push-notification
seems to confuse people into thinking that the user will be
notified/bothered when such a message arrives. This is reinforced by
the fact that iOS uses push notification for exactly that: a way to
notify the user based on a message from a server. See
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/WhatAreRemoteNotif.html.

Since the spec already uses the name PushMessage for the thing
delivered by a push notification
(https://dvcs.w3.org/hg/push/raw-file/tip/index.html#pushmessage-interface),
it seems like push message would be a good replacement for the
current ambiguous name.

Thanks,
Jeffrey Yasskin

P.S. I'm not subscribed to public-webapps@, so please cc me if you
want me to reply.

Re: [push] Consider renaming push notification to push message in the Push API spec

Sure, we will look out for additional potentially confusing term overlap as
suggested.

Thanks,
Bryan Sullivan

On Mar 11, 2014, at 12:38 PM, Michael van Ouwerkerk
mvanouwerk...@google.commailto:mvanouwerk...@google.com wrote:

I think that's a great suggestion Jeffrey.

Specifically, I would like to avoid confusing concepts and terminology in the
Push API with those in Web Notifications: http://www.w3.org/TR/notifications/

This is important because these two APIs are often discussed together: an app
might display a notification to the user after receiving a push message from
the server.

Regards,

Michael

On Mon, Mar 10, 2014 at 6:14 PM, Jeffrey Yasskin
jyass...@google.commailto:jyass...@google.com wrote:
The term push notification in
https://dvcs.w3.org/hg/push/raw-file/tip/index.html#dfn-push-notification
seems to confuse people into thinking that the user will be
notified/bothered when such a message arrives. This is reinforced by
the fact that iOS uses push notification for exactly that: a way to
notify the user based on a message from a server. See
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/WhatAreRemoteNotif.html.

Since the spec already uses the name PushMessage for the thing
delivered by a push notification
(https://dvcs.w3.org/hg/push/raw-file/tip/index.html#pushmessage-interface),
it seems like push message would be a good replacement for the
current ambiguous name.

Thanks,
Jeffrey Yasskin

P.S. I'm not subscribed to public-webapps@, so please cc me if you
want me to reply.

Re: [push] Consider renaming push notification to push message in the Push API spec

Sure, but this is only a reflection of the semantic space of the English
language. Many things can be source of confusion. Understanding context is the
responsibility of the reader. We will do what we can to provide clarifying
guidance on the use of terms, but Push Message is a well-established term, as
well Push Notification. The question, which has to be answered by
understanding the context, is who or what is the recipient. Note that even the
term Server can be tricky as client and server roles can apply to various
software entities executing on different devices or even the same device.

Thanks,
Bryan Sullivan

On Mar 13, 2014, at 8:24 AM, Mark Nottingham
m...@mnot.netmailto:m...@mnot.net wrote:

FWIW, we also have “Server Push” in HTTP/2; that seems confusable as well…

On 11 Mar 2014, at 7:36 pm, Michael van Ouwerkerk
mvanouwerk...@google.commailto:mvanouwerk...@google.com wrote:

I think that's a great suggestion Jeffrey.

Specifically, I would like to avoid confusing concepts and terminology in the
Push API with those in Web Notifications: http://www.w3.org/TR/notifications/

This is important because these two APIs are often discussed together: an app
might display a notification to the user after receiving a push message from
the server.

Regards,

Michael

Thanks,
Jeffrey Yasskin

P.S. I'm not subscribed to public-webapps@, so please cc me if you
want me to reply.

--
Mark Nottingham http://www.mnot.net/

Re: [push-api] Dependency on System Messages

One of the other changes in progress is to include service workers on the 
design of the API. I don't know if that replaces system messages in total but 
the necessary changes will be considered when a new draft is submitted.

Thanks,
Bryan Sullivan

On Mar 13, 2014, at 12:40 PM, Arthur Barstow 
art.bars...@nokia.commailto:art.bars...@nokia.com wrote:

Hi Bryan, Eduardo, All,

While working through the push notification versus push message thread, I 
noticed Push API directly refers to System Messages as defined by SysApps' 
[runtime] spec. Based on the Note at the top of [runtime], it appears work on 
that spec has stopped. As such, what is the plan for the Push API spec 
regarding the dependency on the System Messages feature?

-Thanks, AB

[runtime] http://runtime.sysapps.org/

RE: [push-api] No clear mention of privacy implication of sending data through push service

2014-02-17 Thread SULLIVAN, BRYAN L

Thanks for the comments, Tobie. I will provide an update draft proposal soon to 
address them.
Note also that I'm preparing a proposal to actually include a message body, and 
other enhancements to the current API to broaden support among browsers. I 
should have a draft for review in the next couple of weeks.
Given that such a body would be optional, it would be good in any event to 
include a flow as you propose.

Thanks,
Bryan Sullivan

From: Tobie Langel [mailto:tobie.lan...@gmail.com]
Sent: Monday, February 17, 2014 4:02 AM
To: public-webapps@w3.org
Subject: [push-api] No clear mention of privacy implication of sending data 
through push service

Hi,

Was just skimming through the Push API spec.

I'm aware that no payload is sent with push message for privacy reasons (as 
push service is most certainly a third party), but that isn't mentioned in the 
spec.

I suggest adding a non-normative note that:

1. describes the reasons of this architectural decision (the privacy concern),
2. describes a possible work-around (xhr request to App Server to get the data),
3. eventually mentions some of the benefits (e.g. payload can be always up to 
date even if notification is stale).

Secondly, the very helpful sequence diagram contained in the spec could be 
amended like so (to hint at this work-around):

  ++   ++ ++   ++
  | webapp |   |  user  | |  push  |   |  app   |
  ||   | agent  | | server |   | server |
  ++   ++ ++   ++
  ||  | |
  |-register--|  | |
  ||  | |
  |  (user accepts)   | |
  ||  | |
  ||-setup push service-| |
  ||  | |
  |---success-|  | |
  ||  | |
  |--activate service with PushService attributes-|
  ||  | |
  ||  |--push notification-|
  ||  |   per service API   |
  ||  | |
  || (match to user agent)  |
  ||  | |
  ||--push notification--| |
  || per service protocol | |
  ||  | |
  |(match to webapp)  | |
  ||  | |
  |---system message--|  | |
  ||  | |
  |--XHR GET Request---|
  ||  | |
  |---Payload--|
  ||  | |

Best,

--tobie

[PUSH API] Request for CFC on publication of new WD

2013-07-11 Thread SULLIVAN, BRYAN L

Hi Webapps,

Eduardo and I have uploaded a new ED of the Push API at 
https://dvcs.w3.org/hg/push/raw-file/tip/index.html.

This incorporates a variety of changes based upon comments received since the 
last ED. See https://github.com/telefonicaid/WebAPISpecs/commits/develop/Push 
for details on these changes:

* Correct issues with Pubrules Checker

* moving push notification steps to system messages section

* escaping character

* Push server *may* skip version notifications ...

* if none, registrations() returns 0 length array ...

* Complete example code ...

* Replace references to web intents with push service extension ...

* editorial correction

* renaming appToken to pushRegistrationId

* splitting pushEndpoint into pushEndpoint and appToken

* adding links to promises algorithms

* fixing Promise-related descriptions

* fix example 1 to use Promise

* addressing Jonas' concern about transfering actual content in 
notific... ...

* removing serverProtocols

* changing version to unsigned long long and clarifying when it is 
null... ...

* changing from DOMRequest to Promise

* Add bit about semantics of push notification delivery guarantees

We would like to request a CFC for publication of a new WD based upon this ED.

Thanks,
Bryan Sullivan

RE: Files on IndexedDB

2013-06-11 Thread SULLIVAN, BRYAN L

Comments below.

-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc] 
Sent: Wednesday, June 12, 2013 8:56 AM
To: Arthur Barstow
Cc: pira...@gmail.com; Webapps WG
Subject: Re: Files on IndexedDB

Hi Art,

Actually, the response in [2] says that we should clarify in the spec
that files, blobs and filelists are stored by value rather than by
reference. This is not a normative change since the spec already
defines this behavior. However the behavior is defined somewhat
indirectly which means that it'd make sense to clarify it explicitly.

/ Jonas

bryan It's still not clear to me why you say that File blobs (blobs as 
extended by the File API) are stored by value. The current working 
implementation across multiple shipping browsers would say that File objects 
are not stored by value, but that when read (as in 8.5.4. The readAsText(blob, 
label) method) the current filesystem data is read, not a stored copy. Perhaps 
I'm misunderstanding the intent of this proposed change, and it would not 
actually change current implementations. But the section 8.5.4 is pretty 
clearly (to me) referring to an operation that reads data from the underlying 
filesystem, e.g. While processing the read, as data from the blob becomes 
available... indicating that there is a process of reading from some storage. 
It would not make sense for example if I have a 1GB file that I want my app to 
read, that the browser has to make *two* copies of it - one in some 
browser-temporary/hidden filesystem location (as a copy of the original file) 
and the second, in-memory copy. It would be much more straightforward, and 
support the existing UX, if the browser reads the current filesystem version 
when readAs... methods are called.

Thanks,
Bryan Sullivan 

On Tue, Jun 11, 2013 at 11:24 AM, Arthur Barstow art.bars...@nokia.com wrote:
 Hi - your comment is considered a Last Call comment and it was included in
 the LC's comment tracking document [1].

 In [2], Joshua proposed this comment be addressed/resolved as a feature
 request and as such, it was added to the IDB feature request list [3].

 For the purposes of tracking your comment, please indicate if this
 resolution is acceptable or not.

 -Thanks, ArtB

 [1]
 https://dvcs.w3.org/hg/IndexedDB/raw-file/default/Comments-16-May-2013-LCWD.html
 [2]
 http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0817.html
 [3] http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures

 On 5/30/13 5:24 AM, ext pira...@gmail.com wrote:

 According to IndexedDB specification, File and Blob and FileList objects
 should be allowed to be stored inside IndexedDB doing a shallow copy. On
 Mozilla this is possible, although File and Blob objects are stored
 nativelly on a special place on the hard disk. Chrome is working on it at
 this moment. Problem is, seems they are being duplicated and a copy is
 stored instead of a reference to the original File. I think is not the
 correct way to do it... or at least not always.

 File and FileList objects are only available from Input tags (at this
 moment you can't be able to create them by hand, and also can't be
 downloaded, only Blob objects), so they exists on the user hard disk, so
 it's not necesary to make a duplicate and waste space. It would make sense
 to store a copy inside IndexedDB when you want to store it, but if you want
 to store only some metadata for the File object (for example a hash of the
 file, or a flag for already viewed chapters on a local hard disk stored
 serie) making a copy is useless.

 Also, although is being currently discused, FileList objects are suposed
 to be live objects showing the current status of a directory each time is
 readed (both added, updated and removed File objects), and File objects
 should work the same, working mainly as references to the hard disk status
 that would not be the actual one if they are stored duplicates on the
 database (they will show the status when the File / FileList was stored),
 and specially when the IndexedDB is accessed between reloads.

 On the other hand, Blob objects can be created and downloaded, so it makes
 sense to store duplicates of data that's currently on RAM and would
 disappear after a page reload, in the same way you save your work before
 closing an application.

 So my proposition is about to allow the File and FileList objects being
 stored as actual references to the original hard disk File and FileList
 objects instead of data duplicates, and only store really inside IndexedDB
 data from Blob objects. This way would allow to store references to opened
 File and FileList objects between reloads of the page without requiring to
 the user to re-select them and process them again as new, while allowing to
 store data (also File objects) inside IndexedDB in the form of Blob objects.

RE: Files on IndexedDB

2013-06-11 Thread SULLIVAN, BRYAN L

Update: my comments were referring to the File API, not the IndexedDB API - I 
mistook the context of this thread (somehow) to be about the File API... 
nevermind!

-Original Message-
From: SULLIVAN, BRYAN L 
Sent: Wednesday, June 12, 2013 11:18 AM
To: Jonas Sicking; Arthur Barstow
Cc: pira...@gmail.com; Webapps WG
Subject: RE: Files on IndexedDB

Comments below.

-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc] 
Sent: Wednesday, June 12, 2013 8:56 AM
To: Arthur Barstow
Cc: pira...@gmail.com; Webapps WG
Subject: Re: Files on IndexedDB

Hi Art,

Actually, the response in [2] says that we should clarify in the spec
that files, blobs and filelists are stored by value rather than by
reference. This is not a normative change since the spec already
defines this behavior. However the behavior is defined somewhat
indirectly which means that it'd make sense to clarify it explicitly.

/ Jonas

bryan It's still not clear to me why you say that File blobs (blobs as 
extended by the File API) are stored by value. The current working 
implementation across multiple shipping browsers would say that File objects 
are not stored by value, but that when read (as in 8.5.4. The readAsText(blob, 
label) method) the current filesystem data is read, not a stored copy. Perhaps 
I'm misunderstanding the intent of this proposed change, and it would not 
actually change current implementations. But the section 8.5.4 is pretty 
clearly (to me) referring to an operation that reads data from the underlying 
filesystem, e.g. While processing the read, as data from the blob becomes 
available... indicating that there is a process of reading from some storage. 
It would not make sense for example if I have a 1GB file that I want my app to 
read, that the browser has to make *two* copies of it - one in some 
browser-temporary/hidden filesystem location (as a copy of the original file) 
and the second, in-memory copy. It would be much more straightforward, and 
support the existing UX, if the browser reads the current filesystem version 
when readAs... methods are called.

Thanks,
Bryan Sullivan 

On Tue, Jun 11, 2013 at 11:24 AM, Arthur Barstow art.bars...@nokia.com wrote:
 Hi - your comment is considered a Last Call comment and it was included in
 the LC's comment tracking document [1].

 In [2], Joshua proposed this comment be addressed/resolved as a feature
 request and as such, it was added to the IDB feature request list [3].

 For the purposes of tracking your comment, please indicate if this
 resolution is acceptable or not.

 -Thanks, ArtB

 [1]
 https://dvcs.w3.org/hg/IndexedDB/raw-file/default/Comments-16-May-2013-LCWD.html
 [2]
 http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0817.html
 [3] http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures

 On 5/30/13 5:24 AM, ext pira...@gmail.com wrote:

 According to IndexedDB specification, File and Blob and FileList objects
 should be allowed to be stored inside IndexedDB doing a shallow copy. On
 Mozilla this is possible, although File and Blob objects are stored
 nativelly on a special place on the hard disk. Chrome is working on it at
 this moment. Problem is, seems they are being duplicated and a copy is
 stored instead of a reference to the original File. I think is not the
 correct way to do it... or at least not always.

 File and FileList objects are only available from Input tags (at this
 moment you can't be able to create them by hand, and also can't be
 downloaded, only Blob objects), so they exists on the user hard disk, so
 it's not necesary to make a duplicate and waste space. It would make sense
 to store a copy inside IndexedDB when you want to store it, but if you want
 to store only some metadata for the File object (for example a hash of the
 file, or a flag for already viewed chapters on a local hard disk stored
 serie) making a copy is useless.

 Also, although is being currently discused, FileList objects are suposed
 to be live objects showing the current status of a directory each time is
 readed (both added, updated and removed File objects), and File objects
 should work the same, working mainly as references to the hard disk status
 that would not be the actual one if they are stored duplicates on the
 database (they will show the status when the File / FileList was stored),
 and specially when the IndexedDB is accessed between reloads.

 On the other hand, Blob objects can be created and downloaded, so it makes
 sense to store duplicates of data that's currently on RAM and would
 disappear after a page reload, in the same way you save your work before
 closing an application.

 So my proposition is about to allow the File and FileList objects being
 stored as actual references to the original hard disk File and FileList
 objects instead of data duplicates, and only store really inside IndexedDB
 data from Blob objects. This way would allow to store references to opened
 File and FileList objects

RE: [PUSH API] Scope of the specification

2013-06-03 Thread SULLIVAN, BRYAN L

Thanks for starting this thread, Arnaud. I have some responses below, and look 
forward to discussions on these topics.

Bryan Sullivan 

-Original Message-
From: arnaud.br...@orange.com [mailto:arnaud.br...@orange.com] 
Sent: Monday, June 03, 2013 9:05 AM
To: public-webapps@w3.org
Subject: [PUSH API] Scope of the specification

Greetings,

During the last face to face we had a start of a discussion on what should fall 
within the scope of the PUSH specification. I feel we should go a little 
further on this matter. 

As it is designed right now the whole system requires 3 APIs :
- one between the web application and the browser (the core of this spec)
- one between the push server and the application server 
- one between the push server and the device.

During the face to face I think we agreed that the first two at the very least 
should fall within the scope of the spec, do we feel the third one is trivial 
enough to not require any sort of specification ? 

bryan One key current rationale for leaving this out of scope was not its 
triviality, but rather to be opaque to the different protocols that 
implementations may use between their push server and client, or even different 
bearers (OMA Push for example is spec'd for use across SMS, UDP, TCP, HTTP, 
SIP, and multicast/broadcast bearers - but usually the actual used bearer is 
abstracted from the target application, being a function of a push client on 
device which exposes an API to the applications, e.g. Android's broadcast 
events for WAP Push).

There are other parts that I also feel would require some attention:
- How the push server is discovered and selected (currently the spec speaks of 
an intent server but with intent currently being shelved I am unsure whether 
this is the right path to take. Also it seemed to me that the user journey on 
proxy selection was rather different than the one imagined for web intents).

bryan Service discovery and selection are things that we still need to 
address, and the UI-related obstacles that the browser vendors have reported 
with their Web Intents implementation experiments should not prevent us from 
continuing discussion on these important facets of the web architecture. I 
don't think however that this should be a normative dependency upon the Push 
API as a UA/app interface, but rather a separate spec. That separate spec may 
be useful in establishing a pattern for service discovery and selection that is 
useful for other APIs, e.g. payment, and the actions earlier envisioned for Web 
Intents.

- How a given application registers on the push server and how the push server 
may or may not allow access to its push service (I guess this falls within some 
of the security remarks and the general security model of the solution).

bryan Registration today is a largely manual process of establishing a 
developer relationship with a push service provider. The TOCs for push server 
API use are also service-specific. Going beyond that to enable dynamic 
registration and TOC/policy management is a more ambitious goal, and could be a 
part of the 2nd spec mentioned above, but discovery/selection is likely to be 
an easier thing to spec in the short term.

- How the push server should be designed (I think we agreed that writing some 
informational guidelines that would be non normative would be a good idea).

bryan I agree that operating store-and-forward messaging systems (push being 
one type) or even simple pass-thru push gateways can be complex. We can 
contribute to these guidelines based upon what we have spec'd (going back to 
pre-2000) in WAP Forum / OMA, and learned through operating push services for 
more than 10 years.

//Arnaud

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete 
altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages 
that have been modified, changed or falsified.
Thank you.

RE: Filesystem events

2013-05-29 Thread SULLIVAN, BRYAN L

From: Charles Pritchard [mailto:ch...@jumis.com]
Sent: Wednesday, May 29, 2013 3:08 PM
To: pira...@gmail.com
Cc: public-webapps@w3.org
Subject: Re: Filesystem events

We didn't come to much of a resolution.
It was suggested that the current behavior in browsers was incorrect; that the 
File should become inaccessible if/when it changes.

bryan I disagree, the fact that re-accessing a file object loads the latest 
version of the file is a valuable feature IMO, even if it was not intentional. 
I don't know if preventing that is what you meant, but further to require that 
the user reselect a file if it has changed would be a UX killer.

Thanks,
Bryan Sullivan

RE: Filesystem events

2013-05-29 Thread SULLIVAN, BRYAN L

-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc] 
Sent: Wednesday, May 29, 2013 3:25 PM
To: SULLIVAN, BRYAN L
Cc: Charles Pritchard; pira...@gmail.com; public-webapps@w3.org
Subject: Re: Filesystem events

On Wed, May 29, 2013 at 3:17 PM, SULLIVAN, BRYAN L bs3...@att.com wrote:
 From: Charles Pritchard [mailto:ch...@jumis.com]
 Sent: Wednesday, May 29, 2013 3:08 PM
 To: pira...@gmail.com
 Cc: public-webapps@w3.org
 Subject: Re: Filesystem events

 We didn't come to much of a resolution.
 It was suggested that the current behavior in browsers was incorrect; that
 the File should become inaccessible if/when it changes.

 bryan I disagree, the fact that re-accessing a file object loads the
 latest version of the file is a valuable feature IMO, even if it was not
 intentional. I don't know if preventing that is what you meant, but further
 to require that the user reselect a file if it has changed would be a UX
 killer.

File objects should be immutable. That was one of the core design
principles that they were built around.

If we want input type=file to provide live access to on-disk
files, then new File objects should be returned from
HTMLInputElement.files whenever the on-disk files change. That would
need to be defined by the HTML spec though.

bryan OK, but that sounds like one of those good UA design principles that 
ignores the actual effect upon apps and users. I would prefer to keep this 
bug around until the new/better design is implemented.

RE: Filesystem events

2013-05-29 Thread SULLIVAN, BRYAN L

-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc] 
Sent: Wednesday, May 29, 2013 3:44 PM
To: SULLIVAN, BRYAN L
Cc: Charles Pritchard; pira...@gmail.com; public-webapps@w3.org
Subject: Re: Filesystem events

On Wed, May 29, 2013 at 3:34 PM, SULLIVAN, BRYAN L bs3...@att.com wrote:
 -Original Message-
 From: Jonas Sicking [mailto:jo...@sicking.cc]
 Sent: Wednesday, May 29, 2013 3:25 PM
 To: SULLIVAN, BRYAN L
 Cc: Charles Pritchard; pira...@gmail.com; public-webapps@w3.org
 Subject: Re: Filesystem events

 On Wed, May 29, 2013 at 3:17 PM, SULLIVAN, BRYAN L bs3...@att.com wrote:
 From: Charles Pritchard [mailto:ch...@jumis.com]
 Sent: Wednesday, May 29, 2013 3:08 PM
 To: pira...@gmail.com
 Cc: public-webapps@w3.org
 Subject: Re: Filesystem events

 We didn't come to much of a resolution.
 It was suggested that the current behavior in browsers was incorrect; that
 the File should become inaccessible if/when it changes.

 bryan I disagree, the fact that re-accessing a file object loads the
 latest version of the file is a valuable feature IMO, even if it was not
 intentional. I don't know if preventing that is what you meant, but further
 to require that the user reselect a file if it has changed would be a UX
 killer.

 File objects should be immutable. That was one of the core design
 principles that they were built around.

 If we want input type=file to provide live access to on-disk
 files, then new File objects should be returned from
 HTMLInputElement.files whenever the on-disk files change. That would
 need to be defined by the HTML spec though.

 bryan OK, but that sounds like one of those good UA design principles 
 that ignores the actual effect upon apps and users. I would prefer to keep 
 this bug around until the new/better design is implemented.

I would expect that this doesn't work in most current UAs. Most UAs
likely cache the size of the File inside the File object, and so even
if the file changes on disk you can't see the new size, and possibly
can't read past the cached size.

bryan Last time I tested it, it did work (and that was my reading of the 
spec, at least it did not prohibit the expected behavior I read), but to be 
sure, I retested: as of the current version of Firefox and Chrome, it is 
possible to reload a file with the latest content, without bringing up the file 
requester again. That's the UX I am talking about, if I misunderstood the 
meaning of this discussion. My test is at 
http://bkaj.net/test/webapi/file-api.html.

RE: CfC - working on manifest

2013-05-14 Thread SULLIVAN, BRYAN L

Chaals,

Overall, I think we support this proposal but have some questions I would like 
to get clarifications on:

Maybe I don't recall but is SysApps asking Webapps to take the manifest aspect? 
Or is this something Webapps thinks is its right because of the prior focus on 
Widgets packaging? I don't recall  case of a group unilaterally taking back 
something similar to something else it had worked on in the past.

If SysApps did approve but in the end disapproved with the result, what 
recourse would they have? Woudnt it be better to have this as a joint 
deliverable then?

Thanks,
Bryan Sullivan 

-Original Message-
From: Charles McCathie Nevile [mailto:cha...@yandex-team.ru] 
Sent: Tuesday, May 14, 2013 6:29 AM
To: public-webapps WG
Subject: CfC - working on manifest

Hi,

at the face to face meeting we agreed to take back the work on a manifest  
specification for apps, based on the current manifest draft from sysapps  
[1] that was developed from the proposal [2] included in our charter [3],  
and to leave the runtime part of the work with Sysapps.

This is a formal Call for Consensus on that resolution. Silence will be  
taken as assent. Responses will be accepted up to the end of the day  
Tuesday 21 May.

for the chairs
Chaals

[1] http://manifest.sysapps.org/
[2] http: 404 (and people ask me why I care where things get published)
[3] http://www.w3.org/2012/webapps/charter/Overview.html

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
   cha...@yandex-team.ru Find more at http://yandex.com

RE: CfC - working on manifest

2013-05-14 Thread SULLIVAN, BRYAN L

Thanks for the clarifications - we support it.
And I will try to do less multitasking at F2F's!

Thanks,
Bryan Sullivan 

-Original Message-
From: Charles McCathie Nevile [mailto:cha...@yandex-team.ru] 
Sent: Tuesday, May 14, 2013 7:47 AM
To: public-webapps WG; SULLIVAN, BRYAN L
Subject: Re: CfC - working on manifest

On Tue, 14 May 2013 18:39:34 +0400, SULLIVAN, BRYAN L bs3...@att.com  
wrote:

 Chaals,

 Overall, I think we support this proposal but have some questions I  
 would like to get clarifications on:

Minutes of the discussion, to help jog your memory:  
http://www.w3.org/2013/04/25-webapps-minutes.html#item04 (I apoogise for  
not linking those from the original CfC message).

 Maybe I don't recall but is SysApps asking Webapps to take the manifest  
 aspect?

Yes.

 Or is this something Webapps thinks is its right because of the prior  
 focus on Widgets packaging? I don't recall  case of a group unilaterally  
 taking back something similar to something else it had worked on in the  
 past.

No, the idea is that we all agree on this.

 If SysApps did approve but in the end disapproved with the result, what  
 recourse would they have?

Comment on the spec and say that's terrible, it should be If  
necessary as formal objections to moving forward. As a practical matter I  
think nearly all of sysapps members are also represented in webapps. So I  
would be surprised if there were a real issue.

 Woudnt it be better to have this as a joint deliverable then?

No, there is a handful of frustrating overhead to do that which, if it is  
as unnecessary as it seems in this case, the people who would have to deal  
with it (chairs, editors, staff contacts) preferred to avoid.

 Thanks,
 Bryan Sullivan

 -Original Message-
 From: Charles McCathie Nevile [mailto:cha...@yandex-team.ru]
 Sent: Tuesday, May 14, 2013 6:29 AM
 To: public-webapps WG
 Subject: CfC - working on manifest

 Hi,

 at the face to face meeting we agreed to take back the work on a manifest
 specification for apps, based on the current manifest draft from sysapps
 [1] that was developed from the proposal [2] included in our charter [3],
 and to leave the runtime part of the work with Sysapps.

 This is a formal Call for Consensus on that resolution. Silence will be
 taken as assent. Responses will be accepted up to the end of the day
 Tuesday 21 May.

 for the chairs
 Chaals

 [1] http://manifest.sysapps.org/
 [2] http: 404 (and people ask me why I care where things get published)
 [3] http://www.w3.org/2012/webapps/charter/Overview.html

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
   cha...@yandex-team.ru Find more at http://yandex.com

RE: [IndexedDB] How to recover data from IndexedDB if the origin domain don't exist anymore?

2013-01-09 Thread SULLIVAN, BRYAN L

Perhaps this problem indicates a real limitation in the same-origin policy as 
root for browser data. In a somewhat related point at TPAC for example I 
pointed out that the value of using IndexedDB for media storage - e.g. GBs of 
music or videos - will be severely limited if I can't switch my web-based media 
player application from one origin to another.

Perhaps what we need (and I am ducking as I say this) is a meta tag for web 
pages, e.g.
meta name=previously-known-as content=http://olddomain.com:80;
or
meta name=same-as content=http://olddomain.com:80;

This could then be used by the browser to allow the user (always in control of 
such decisions) to grant the new origin to take ownership of (or at least gain 
read/write access to) any existing data of the old origin.

Thanks,
Bryan Sullivan

From: pira...@gmail.com [mailto:pira...@gmail.com]
Sent: Tuesday, January 08, 2013 11:37 AM
To: Todd Blanchard
Cc: public-webapps@w3.org
Subject: Re: [IndexedDB] How to recover data from IndexedDB if the origin 
domain don't exist anymore?

Hacky, but nice trick (really, I like it :-) ). My question was more related 
about looking for a solution available for non-techies users, or give a warning 
about a (valid?) corner-case on the specification.

(I'm going to add an issue on my project tracker to remind me to develop your 
idea, it's really simple and useful :-) )

2013/1/8 Todd Blanchard 
toddvblanch...@gmail.commailto:toddvblanch...@gmail.com
As a practical matter, you could just make an entry in your /etc/hosts mapping 
the domain to localhost and write a web page that dumps the indexeddb as json.  
Serve that from your local web server and hit it with your browser.


On Jan 8, 2013, at 7:08 AM, pira...@gmail.commailto:pira...@gmail.com wrote:


I have been looking on Internet and reading the spec but didn't be able to get 
at answer.

Let's see the next situation: I've developed a webapp that use IndexedDB to 
store personal data. It's pure client-side and server-less, being all the 
content of the webapp just static files and served with static web servers and 
CDNs, so all the user data is stored on IndexedDB on the user's computer and 
not any other place (there's no a database server that could be accesed in 
any form in any place at all).

I know that IndexedDB use a same-domain policy to isolate the access to the 
data, but maybe one day the domain of my webapp could dissapear for any reason 
(bankrupcy, forgot to pay the domain renoval, legal issues, system fail... 
whatever) so I can't be able to access to the page to download the webapp that 
would allow to me to access to MY data in MY computer.

At this moment, I've developed a way to make backups of the content of the 
IndexedDB so it could be imported on the IndexedDB of other domain (and also 
on other computer if neccessary) but I find it bad for usability, so my 
question is, there's a way so an IndexedDB database could be shared by several 
domain unrelated webapps? Maybe defining in some way a fake origin for the 
IndexedDB object that all the webapps could have in common (in some way like a 
magic word), or the specification doesn't allow this possiblity at this 
moment? If so, how I could be able to do it?

Greetings and thank you very much, Jesús Leganés Combarro.

Jesús Leganés Combarro
pira...@gmail.commailto:pira...@gmail.com
http://github.com/piranna/ShareIt


--
Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de 
sitios diferentes, simplemente escribe un sistema operativo Unix.
- Linus Tordvals, creador del sistema operativo Linux




--
Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de 
sitios diferentes, simplemente escribe un sistema operativo Unix.
- Linus Tordvals, creador del sistema operativo Linux

RE: FileSystem compromise spec

2012-11-30 Thread SULLIVAN, BRYAN L

 -Original Message-
 From: Arthur Barstow [mailto:art.bars...@nokia.com]
 Sent: Friday, November 30, 2012 6:46 AM
 To: ext Eric U; Doug Schepers
 Cc: Web Applications Working Group WG
 Subject: Re: FileSystem compromise spec

 On 11/15/12 7:39 PM, ext Eric U wrote:
  As discussed at TPAC, there's little support for the current FileSystem 
  API, but
  some support for a new API, and I promised to put forth a compromise 
  proposal.
  In order to do that, I'd like to hear 1) what kinds of changes would make it
  more popular; 2) who I'm trying to convince.  There are a number of folks 
  who
  have said that they're not interested in a FileSystem API at all, so I'd 
  rather
  concentrate my efforts on those with skin in the game.

Note that even though we are a service provider and not a browser vendor, I do 
consider us to have skin in the game.

 * It's designed to handle both the sandbox and the
   outside-the-sandbox use cases.  For folks interested in just the 
  sandbox and
   no future expansions, that seems like wasted effort, and a 
  sandbox-only API
   could be simpler.  It's not clear to me that there is anyone 
  interested in
   just the sandbox and no future expansions, but if there is, please 
  speak up.
   I've certainly heard from folks with the opposite goal.

I am still looking for evidence that IndexedDB provides a high-performance, 
scalable, cross-domain alternative to native filesystem access. I've seen 
conflicting information on that, and will gather this information with whatever 
tests can be found to validate performance of browsers for IndexedDB.

 It seems like it would be useful to look at these various file and
 database specs from a high level use case perspective (f.ex. one way to
 address UC X is to use spec X). If anyone is aware of some related
 docs, please let me know. Doug - wondering aloud here if this is
 something webplatform.org might cover or if you know of someone that
 might be interested in creating this type of documentation?

In the Web  TV IG I will be leading a task force specifically to address the 
recording and storage of media use cases, where storage options are the key 
focus. If someone can prove to us that in-the-sandbox storage addresses the 
needs (high-performance, scalable, cross-domain) then great; otherwise we will 
keep looking.

  I'd like to hear from folks who are interested, but not in the current spec.

I note that this request seems to exclude (or recommend silence) of 
counter-points from those that *want the current specs* as mentioned by Eric. 
So if there is a lack of contribution from those that support the other use 
cases noted (e.g. out-of-the-sandbox storage), it should not be taken as 
consensus with the alternative as discussed in this thread.

Thanks,
Bryan Sullivan

RE: CfC: publish FPWD of Push API; deadline October 12

2012-10-15 Thread SULLIVAN, BRYAN L

Hi Art,

An issue has been added as requested in the current draft [1].

[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: Monday, October 15, 2012 4:15 AM
 To: public-weba...@w3c.org; SULLIVAN, BRYAN L; EDUARDO FULLEA CARRERA
 Subject: Re: CfC: publish FPWD of Push API; deadline October 12
 
 On 10/5/12 7:38 AM, ext Arthur Barstow wrote:
  The Push API Editors would like to publish a First Public Working
  Draft of their spec and this is a Call for Consensus to do so, using
  the following spec as the basis
  http://dvcs.w3.org/hg/push/raw-file/default/index.html.
 
  This CfC satisfies the group's requirement to record the group's
  decision to request advancement.
 
  By publishing this FPWD, the group sends a signal to the community to
  begin reviewing the document. The FPWD reflects where the group is on
  this spec at the time of publication; it does _not_ necessarily mean
  there is consensus on the spec's contents.
 
  If you have any comments or concerns about this CfC, please reply to
  this e-mail by October 12 at the latest. Positive response is
  preferred and encouraged and silence will be considered as agreement
  with the proposal.
 
 Although there were no objections to this CfC, Jonas raised a number of
 concerns in
 http://lists.w3.org/Archives/Public/public-
 webapps/2012OctDec/0042.html.
 Although we will have an opportunity to discuss these comments in Lyon,
 I would like the spec Editors to add an Issue Block in the Security
 and Privacy concerns section and include a link to Jonas' comment.
 
 Bryan, Eduardo - I will contact you off-list about preparing the spec
 for FPWD. (See http://www.w3.org/wiki/Webapps/SpecEditing if you are
 unfamiliar with the W3C's TR publication process.)
 
 -Thanks, AB

RE: Moving File API: Directories and System API to Note track?

2012-10-04 Thread SULLIVAN, BRYAN L

 -Original Message-
 From: Olli Pettay [mailto:olli.pet...@helsinki.fi]
 Sent: Thursday, October 04, 2012 3:48 AM
 To: SULLIVAN, BRYAN L
 Cc: Maciej Stachowiak; Glenn Maynard; Eric U; public-webapps@w3.org
 Subject: Re: Moving File API: Directories and System API to Note track?

 On 09/26/2012 01:32 AM, SULLIVAN, BRYAN L wrote:
  *From:*Maciej Stachowiak [mailto:m...@apple.com]
  *Sent:* Tuesday, September 25, 2012 2:59 PM
  *To:* Glenn Maynard
  *Cc:* Eric U; o...@pettay.fi; public-webapps@w3.org
  *Subject:* Re: Moving File API: Directories and System API to Note
 track?

  Hi Glenn,

  I read over your points. But I don't think they would change Apple's
 calculation about exposing an API to the real user filesystem in Safari,
  particularly as specified. I do think that my more minimal API might
 also be a better fit for the real filesystem use case, as it removes a
 bunch of
  unnecessary levels of indirection and abstraction that exist in the
 other proposals. But I think it is unlikely we would expose that aspect.

  We are still open to solving the sandboxed local storage area use
 case, with a more minimal API. But first we'd like to understand why
 those use
  cases can't be solved with targeted additions to IndexedDB (see forked
 thread).

  Can IndexedDB support the use case of managing a media or document
 library on the local device, in which the size of library can run into
 hundreds or
  files and gigabytes of storage?
 I don't see any technical problems with that.

Other than hard limits on storage per origin and how the virtual filesystem 
would be organized and managed, neither do I, but I am not an expert in browser 
design, that's why I asked the question. If there are no technical problems, 
anyone have thoughts on how soon we can expect to see browsers that provide a 
virtual filesystem implementation based upon Indexed DB?

  Local storage of media is one of the key capabilities needed to enable
 HTML5-based offline media players as a
  realistic option. If the browser can effectively provide a virtual
 filesystem with performance characteristics equivalent to the underlying
 OS, then
  perhaps IndexedDB may suffice for filesystem access. But which
 browsers intend to support that level of functionality via IndexexDB?

 Isn't that part of IndexedDB, to be able to store files efficiently in
 it. So I would assume all the implementations will
 support that.

I don't think specific efficiency objectives are a normative requirement of 
Indexed DB, but the question was more whether browser vendors would claim that 
their Indexed DB implementation will provide performance equivalent to the 
underlying OS. Apart from the technical challenges, it's unrealistic to use 
Indexed DB for this purpose if the performance cannot match the underlying OS.

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

2012-09-26 Thread 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] http://www.w3.org/2008/webapps/wiki/PubStatus

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

2012-09-26 Thread 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 | 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

Re: Push API draft update

2012-08-27 Thread SULLIVAN, BRYAN L

Hi Art,

Can you update the Webapps Publication Status page to add Eduardo as co-editor 
of the Push API draft?

We are looking forward to feedback on this update, with the goal of getting to 
FPWD by TPAC if possible.

Thanks,
Bryan Sullivan 
+

From: EDUARDO FULLEA CARRERA e...@tid.es 
Date: Wed, 22 Aug 2012 07:48:49 +0200
To: public-webapps (public-webapps@w3.org) public-webapps@w3.org 
Cc: bs3...@att.com bs3...@att.com 
Message-id: 492d97b30609c54fa9ff98b847ea5682b975989...@exclu2k7.hi.inet 
Hi all,

Bryan Sullivan and myself have been working together on updating the Push API 
draft based upon feedback received and the work being driven by Mozilla and 
Telefonica to build a Push solution for Firefox OS (B2G).

You can find it at: http://dvcs.w3.org/hg/push/raw-file/default/index.html


This update does not intend to address yet each and every comment received, as 
some may deserve further discussions, but we think is a good step forward. We 
are looking forward to receiving your feedback.

Thanks and regards,
Eduardo Fullea
Telefonica Digital


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

RE: Push API draft uploaded

2012-06-06 Thread SULLIVAN, BRYAN L

Comment inline.

Thanks,
Bryan Sullivan 

-Original Message-
From: Tobie Langel [mailto:to...@fb.com] 
Sent: Tuesday, June 05, 2012 12:28 PM
To: Mounir Lamouri; public-webapps@w3.org
Subject: Re: Push API draft uploaded

On 6/5/12 4:00 PM, Mounir Lamouri mou...@lamouri.fr wrote:

On 05/31/2012 03:28 PM, Tobie Langel wrote:
 I'm probably missing something here, but notifications don't seem to be
 going through a system- / browser-wide notification panel from which the
 user can decide whether or not to navigate to an application. In other
 words, it looks like we're considering server -- app push
notifications,
 rather than server -- user push notifications.

 If that's case, how are we planning to handle waking up application A
 without disrupting the experience of the user currently busy using
 application B in the foreground (thinking essentially of mobile here)?

 Are we going to wake up application B but run it as a background app? If
 so, where is that behavior defined? Is that akin to a WebWorker or more
of
 a headless window? What's the life-cycle of such an app? Also, how can
 this app alert the user that it has something new for him? Do we also
have
 system level notifications in the work?

 If a given notification's sole purpose is to advise the user of some
 information he may or not want to act upon (e.g.: you have new mail),
 what are the benefits of waking up the application (or even spawning a
 worker) to do so? That seems like it would drain the battery of mobile
 devices for little purpose.

 Finally, aren't we conflating the notion of background work following a
 remote server or system event with that of push notification to the
user?

 An example of background work following a remote server event would be
the
 background update of daily news for a newspaper application. A remote
 server would send an event to the system / browser which itself would
 launch a WebWorker, that worker would perform the necessary io to upload
 the fresh content and save it in a db.

 An example of background work following a system event would be a
 location change event spawning a background worker which itself either
 stored the coordinates in a db or sent them to a remote server, e.g.
for a
 cycling app tracking your rides.

 Example of push notifications for the user are things like You've got a
 new message, It's Emma's birthday today, etc. The user can decide to
 act upon them (i.e. follow the provided link) or not, but until he does,
 there's no reason to launch an app or even a worker.

 Note that similar notifications would also need to be issued by
background
 workers / windows. E.g. The worker spawned above to upload fresh content
 for the newspaper app would be able to send a notification to the user
 when it's done (e.g. Today's news are  been downloaded.)

 Sorry if the above feels a bit like a brain dump. I'm really struggling
to
 understand the scope of this proposal. :-/

Actually, our System Message API [1] seems to answer most of those
questions: an application will be able to specify a worker or a page to
use when handling a message so it will be able to just run stuff in the
background and depending on what happened do something like show a
notification (via Desktop Notifications) or update a DB, or whatever.

[1]
https://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/a3
c6e4c31d04b663/

Thanks for the link!

While it's possible to display push notifications to the user via this
proposal (push notification spawns a worker which notifies the user via
Desktop Notification), on mobile it's probably a quantifiable waste of
battery life compared to push notifications that are directly aimed at the
user.

For applications built in a more traditional way (with server side
rendering, etc.), it still feels like providing the data in query params
should be investigated before it's dismissed.

Overall, I feel like writing down use cases and requirements would be
something useful to do at this point. What do you think?

bryan Here is the thread for the set of use cases I submitted for this API 
during the rechartering: 
http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0008.html. 
Additional use cases are welcome, and we can capture them and derived 
requirements on the Webapps wiki. I created a page for this: 
http://www.w3.org/2008/webapps/wiki/Push_API 

--tobie

RE: Push API draft uploaded

2012-06-01 Thread SULLIVAN, BRYAN L

Responses inline.

Thanks,
Bryan Sullivan 

-Original Message-
From: Tobie Langel [mailto:to...@fb.com] 
Sent: Thursday, May 31, 2012 6:29 AM
To: public-webapps@w3.org
Subject: Re: Push API draft uploaded

On 5/30/12 11:14 AM, Mounir Lamouri mou...@lamouri.fr wrote:

 * I guess the idea of |onmessage| is that the PushService instance will
 get an event when the backend will push a notification to the webapp.
 However, I wonder how you do handle the situation when the application
 is actually not being ran. Or should we wait for it to be launched?
 Anyhow, coupling the URL request and the event handling at the same
 place seems weird.

 bryan Not at all. This is the way that EventSource works for example
(the message handler is overtly associated with the request to a
specific service URL). I'm not sure what you mean by when the
application is actually not being ran... if you mean when the app is
not running, the answer is yes, the app should be started and the
event then delivered to it.

 Running a webapp/website then sending an event to it seems a rather hard
 task. This is actually what motivated the System Message Handler API.

 bryan I'm not sure how it's hard; the Webapp just arranges for Push
message delivery when it is invoked, and events are delivered to the
object that represents the service arrangement (whether connection-based
or connectionless or whatever). I may be missing your counterpoint.

I wasn't clear I think. If you start an application because of a
particular event, the application has no way to know it has been started
because of the event until the event is actually sent. But the event
will be sent at a point during load (or after) and in the meantime, the
application might show a UI as if it was simply started by the user. So
you might have a weird UI flickering where something will be shown and
very quickly will be changed to something else because of the push
notification coming.

Agreed with Mounir here. While passing an event to a running app makes
sense (and already exists in the form of EventSource) it really doesn't
for apps which are not running. Passing the event data as query params
seems more suitable in that case.

bryan If the event data can be passed through a fragment (e.g. there are no 
major limitations on that approach), and easily discovered/accessed by the app, 
then that would be a good approach. Can you provide an example of how that 
would work?

 * If we want want a |wakeup| attribute, this might need to live in the
 manifest as Jose suggested. In general, I wonder if that should be
 something the UA requests. I would understand why the UA would ignore
 |wakeup = true| but I wouldn't understand why it should always follows
 the passed value.

 bryan The wakeup feature might be turned on by the app through an
interface with the user, and used sometimes and others not per the
needs of the app and preferences of the user (app managed). If it's in
the manifest, it's fixed. I don't believe the UA should ignore the
requirements of the app, when the user has given their permission for
its operation as needed (both by browsing/installing the app, and
overtly by approving Push service use).

 I'm not sure I understand how the user would give its permission here.

 bryan By navigating to the Webapp (implicitly, in the case that the
Webapp had previously been permitted access to Push services by the
user), and by accepting the UA's prompt as to whether this app should be
allowed to receive Push messages the first time the user navigates to it
(explicitly).

So the user doesn't really give its permission to the app to wakeup the
device but to the app to be able to receive push notifications. Then,
the app is the only one deciding if it will wakeup the device or not.
I'm not a big fan of that approach but I don't really have a better idea
for the moment.

I'm probably missing something here, but notifications don't seem to be
going through a system- / browser-wide notification panel from which the
user can decide whether or not to navigate to an application. In other
words, it looks like we're considering server -- app push notifications,
rather than server -- user push notifications.

bryan Correct, the objective is application messaging, not user messaging. 
Like other aspects of the UX e.g. that supported by the Web since AJAX became 
popular, we don't think it's necessary or effective to require the user to be 
involved in all client-server interactions.

If that's case, how are we planning to handle waking up application A
without disrupting the experience of the user currently busy using
application B in the foreground (thinking essentially of mobile here)?

bryan Apps that can be automatically woken up would benefit from need 
enabling cooperative design that results in a good UX, e.g. the ability to be 
invoked and startup in the background, if there is another foreground app 
(whether in the Web runtime or a native app), and inform the user through

RE: [admin] Mail List Policy, Usage, Etiquette, etc. Top-posting

2012-06-01 Thread SULLIVAN, BRYAN L

Response inline.

Thanks,
Bryan Sullivan 

-Original Message-
From: Tobie Langel [mailto:to...@fb.com] 
Sent: Thursday, May 31, 2012 4:06 PM
To: SULLIVAN, BRYAN L; ife...@google.com; Karl Dubost
Cc: WebApps WG
Subject: Re: [admin] Mail List Policy, Usage, Etiquette, etc.  Top-posting

On 5/31/12 11:58 PM, SULLIVAN, BRYAN L bs3...@att.com wrote:

bryan How about a practical suggestion for the (probably many) of us
that have to use Microsoft Outlook?

From: http://wiki.whatwg.org/wiki/FAQ#Mailing_List

If you use Outlook or Outlook Express, you can use either Outlook-QuoteFix
[1] or OE-QuoteFix[2]. These plugins fix several of Outlook's problems
with sending properly formatted emails.

bryan Sorry, I should have said Outlook as typically approved by corporate 
IT departments which does not include plugins.

--tobie

---
[1]: http://home.in.tum.de/~jain/software/outlook-quotefix
[2]: http://home.in.tum.de/~jain/software/oe-quotefix

RE: Is Quota Management API ready for First Public Working Draft?

2012-05-31 Thread SULLIVAN, BRYAN L

I support the FPWD publication.

Thanks,
Bryan Sullivan 

-Original Message-
From: Arthur Barstow [mailto:art.bars...@nokia.com] 
Sent: Tuesday, May 29, 2012 6:40 AM
To: ext Kinuko Yasuda; WebApps WG
Subject: Is Quota Management API ready for First Public Working Draft?

Hi Kinuko, All - what are people's thoughts on whether or not the Quota 
Management API spec is ready for First Public Working Draft?

A rule of thumb for FPWD is that the ED's scope should cover most of 
the expected functionality although the depth of some functionality may 
be very shallow, and it is OK if there are open bugs/issues.

-Thanks, Art

On 5/29/12 12:30 AM, ext Kinuko Yasuda wrote:
 On Wed, May 23, 2012 at 9:32 PM, Anne van Kesteren ann...@annevk.nl 
 mailto:ann...@annevk.nl wrote:

 On Wed, May 23, 2012 at 2:05 PM, Kinuko Yasuda
 kin...@chromium.org mailto:kin...@chromium.org wrote:
  https://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html

 I noticed something else. StorageInfo is marked as Supplemental and
 NoInterfaceObject, but I do not think either is meant to be used here.
 Supplemental has been replaced by partial interface (rather than
 [Supplemental] interface), but is only supposed to be used if this
 is not the original definition (and I do not think StorageInfo is
 defined elsewhere). NoInterfaceObject is used prevent certain
 interfaces from being prototyped, but I do not think we want that here
 either.

 Oops.. thanks very much for pointing out those mistakes.
 You're right, neither Supplemental nor NoInterfaceObject look 
 appropriate here.
 I dropped them from the draft.

 https://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html

 Thanks!

RE: [admin] Mail List Policy, Usage, Etiquette, etc. Top-posting

2012-05-31 Thread SULLIVAN, BRYAN L

bryan Comment inline.

From: Ian Fette (イアンフェッティ) [mailto:ife...@google.com] 
Sent: Tuesday, May 29, 2012 10:42 AM
To: Karl Dubost
Cc: WebApps WG
Subject: Re: [admin] Mail List Policy, Usage, Etiquette, etc.  Top-posting

On Tue, May 29, 2012 at 10:32 AM, Karl Dubost ka...@opera.com wrote:

Le 29 mai 2012 à 12:59, Ian Fette (イアンフェッティ) a écrit :
 And your modified reply causes GMail not to collapse the replied-to text
seems to be a GMail issue.

[…]
 resolved by using an up-to-date MUA.
Dare putting a list somewhere?

Sure, how about:

• Thunderbird 12
• GMail
• Mail.app
• Opera Mail 11.64
bryan How about a practical suggestion for the (probably many) of us that 
have to use Microsoft Outlook? In my experience the conversion of rich text or 
html to plain text involves significant one-way conversion in the content. And 
it's not clear at all how to get the towers effect, so emails end up with a 
combination of MUA-applied formatting and adhoc formatting. I think unless W3C 
(1) mandates all email discussion be done through the mail archive website, (2) 
enabled the ability to respond on the archive website (and not just invoke the 
default MUA), and (3) enforces the towers effect in replies to ensure 
consistency, we will not achieve effective, consistent use of plain text and 
inline commenting for W3C email.

RE: Push API draft uploaded

2012-05-31 Thread SULLIVAN, BRYAN L

Responses inline.

Thanks,
Bryan Sullivan 
-Original Message-
From: Mounir Lamouri [mailto:mou...@lamouri.fr] 
Sent: Wednesday, May 30, 2012 2:15 AM
To: public-webapps@w3.org
Subject: Re: Push API draft uploaded

On 05/29/2012 06:13 PM, SULLIVAN, BRYAN L wrote:
 * I wonder if it is really useful to have clients requesting a specific
 Push service. I totally understand why a user would request to use his
 preferred Push service but that is part of the UA. I would tend to think
 we should not add that parameter until it's proven to be needed by some
 consumer of the API. Adding it would be simple; removing it might not be
 an option. Also, allowing a website to chose the Push service might
 break the entire idea of decentralization here: you might end up with
 most websites requesting to use push.popularservice.com.

 bryan If a service is effective and thus popular, why shouldn't it be 
 accessible to developers? Rather than break decentralization, this 
 flexibility enables it IMO, so I think there is a misunderstanding 
 somewhere. To enable some degree of Push service (and thus service provider) 
 flexibility, I have also proposed that we could use Web Intents as a way to 
 allow the user to select the service provider, but if the app has particular 
 requirements (e.g. security or delivery methods/bearers), I see no reason 
 why we should obfuscate the developer intent by making the user play the 
 match maker. The requested service URL also provides means to negotiate 
 additional functionality/options between the app and the Push service 
 directly e.g. as above (e.g. security, delivery methods/bearers, application 
 characteristics, ...).

 I don't how this could be related to Web Intents? Picking the service
 provider should be up to the UA (using whichever method the UA feels
 appropriate). If a website *needs* a specific service provider that
 means this API has been a failure so I wouldn't add a parameter that
 would help this happen.

 bryan The concept of service provider selection by the user (in essence the 
 provider of some functionality distributed as Web pages/applications/workers 
 etc) is fundamental to the Web Intents concept, so it seemed natural to me to 
 consider that for this API. I don't think UA's should be exclusively 
 responsible for service provider selection, for this purpose or others. If 
 service providers can be more flexibly integrated through APIs such as Web 
 Intents IMO that is good for the Web.

I do not understand why a concept should be used in this specification
because it is used in Web Intents. And I do not understand why making an
API integrated with Web Intents is good for the Web. Really

bryan The concept of a requested service URL is not in this spec because the 
concept is used in or borrowed from Web Intents. The concept is there because 
it allows developers the flexibility of Push service provider selection. On its 
own, it has no dependency upon Web Intents. I mention Web Intents only to 
illustrate that as an additional potential mechanism, it can be considered as a 
specific way to get the user involved in the Push service provider selection, 
if the developer has no preference in the matter.

 * |readyState| should be a DOMString.

 bryan The jury is out on this, AFAICT. It's a short in EventSource and 
 XHR. I was following their lead.

 I don't know for XHR but the new way is DOMString for multiple
 reasons. I believe Ms2ger pointed you to a link which likely explains those.

 bryan If we can get Webapps resolution on that as a recommended design 
 approach going forward, as I said I am open to this. Perhaps the XHR and 
 EventSource editors can voice an opinion here?

XHR just can't be changed, this is why it is keeping integers instead of
string for errors. I do not know for EventSource. Anyhow, I'm not going
to argue more on that subject.

 * I guess the idea of |onmessage| is that the PushService instance will
 get an event when the backend will push a notification to the webapp.
 However, I wonder how you do handle the situation when the application
 is actually not being ran. Or should we wait for it to be launched?
 Anyhow, coupling the URL request and the event handling at the same
 place seems weird.

 bryan Not at all. This is the way that EventSource works for example (the 
 message handler is overtly associated with the request to a specific service 
 URL). I'm not sure what you mean by when the application is actually not 
 being ran... if you mean when the app is not running, the answer is yes, 
 the app should be started and the event then delivered to it.

 Running a webapp/website then sending an event to it seems a rather hard
 task. This is actually what motivated the System Message Handler API.

 bryan I'm not sure how it's hard; the Webapp just arranges for Push message 
 delivery when it is invoked, and events are delivered to the object that 
 represents the service arrangement (whether connection-based

RE: Push API draft uploaded

2012-05-29 Thread SULLIVAN, BRYAN L

No, the proposal at https://wiki.mozilla.org/Services/Notifications/Push/API. 
This was mentioned by Jonas at the Webapps meeting as the way that Mozilla is 
looking at this API. In that API there are two methods: 
requestRemotePermission() and checkRemotePermission();

But also separately, I am considering how Web Intents can be used for API 
service provider discovery, and use.

Thanks,
Bryan Sullivan 

-Original Message-
From: Mounir Lamouri [mailto:mou...@lamouri.fr] 
Sent: Tuesday, May 29, 2012 2:48 AM
To: public-webapps@w3.org
Subject: Re: Push API draft uploaded

On 05/25/2012 04:00 PM, SULLIVAN, BRYAN L wrote:
 [...] I am following the Mozilla lead on registering the intent to receive 
 messages, [...].

I'm not sure I understand. Do you mean the proposal on the wiki page is
proposing to use intents?

--
Mounir

RE: Push API draft uploaded

2012-05-29 Thread SULLIVAN, BRYAN L

Responses inline.

Thanks,
Bryan Sullivan 
-Original Message-
From: Mounir Lamouri [mailto:mou...@lamouri.fr] 
Sent: Tuesday, May 29, 2012 3:06 AM
To: public-webapps@w3.org
Subject: Re: Push API draft uploaded

On 05/26/2012 05:06 AM, SULLIVAN, BRYAN L wrote:
 * As far as I understand it, |requestRemotePermission| and
 |checkRemotePermission| could be one single method which could be named
 something like |getPushServiceUrl|. The only difference between those
 two methods is the permission asking part but that should stay as a UA
 decision. Given that the method is anyway asynchronous, the UA can do
 whatever wanted before sending a result. Showing a permission prompt
 could be one of those.

 bryan I agree that these methods could collapse into one. But as this 
 interface was based upon the Mozilla proposal 
 (https://wiki.mozilla.org/Services/Notifications/Push/API) I would like to 
 get the author's view on the potential to collapse the two methods into one.

I wouldn't name the proposal on the wiki page as Mozilla's proposal.
This wiki is public and what is described is far from being a finished work.
In addition, the wiki page is quite explicit about the existence of
those two methods and the given reasons are quite invalid.

bryan OK, I am open to collapsing these two methods into one, and will update 
the draft with a proposal for that.

 * I wonder if it is really useful to have clients requesting a specific
 Push service. I totally understand why a user would request to use his
 preferred Push service but that is part of the UA. I would tend to think
 we should not add that parameter until it's proven to be needed by some
 consumer of the API. Adding it would be simple; removing it might not be
 an option. Also, allowing a website to chose the Push service might
 break the entire idea of decentralization here: you might end up with
 most websites requesting to use push.popularservice.com.

 bryan If a service is effective and thus popular, why shouldn't it be 
 accessible to developers? Rather than break decentralization, this 
 flexibility enables it IMO, so I think there is a misunderstanding somewhere. 
 To enable some degree of Push service (and thus service provider) 
 flexibility, I have also proposed that we could use Web Intents as a way to 
 allow the user to select the service provider, but if the app has particular 
 requirements (e.g. security or delivery methods/bearers), I see no reason why 
 we should obfuscate the developer intent by making the user play the match 
 maker. The requested service URL also provides means to negotiate additional 
 functionality/options between the app and the Push service directly e.g. as 
 above (e.g. security, delivery methods/bearers, application characteristics, 
 ...).

I don't how this could be related to Web Intents? Picking the service
provider should be up to the UA (using whichever method the UA feels
appropriate). If a website *needs* a specific service provider that
means this API has been a failure so I wouldn't add a parameter that
would help this happen.

bryan The concept of service provider selection by the user (in essence the 
provider of some functionality distributed as Web pages/applications/workers 
etc) is fundamental to the Web Intents concept, so it seemed natural to me to 
consider that for this API. I don't think UA's should be exclusively 
responsible for service provider selection, for this purpose or others. If 
service providers can be more flexibly integrated through APIs such as Web 
Intents IMO that is good for the Web.

 * I'm not sure why you have a |requestUrl| attribute in PushService. Do
 you have any use case for that?

 bryan The use case is that an app can have multiple Push service requests 
 active at a time, with different URLs. In order to be able to associate each 
 PushService object with a specific set of options or services for example, it 
 needs to know what URL was used when the PushService object was created. The 
 intent is similar to that of EventSource, which has the url attribute for a 
 similar purpose (at least that is how I have used it). And since the 
 checkRemotePermission() method needs to verify the permission for the same 
 URL, it is better to have the resolved form of the URL available as an 
 attribute, so that it's easy to call the checkRemotePermission() method for 
 the right URL (as the absolute URL may have changed since the original 
 resolution).

The resolving part seems quite useless because contrary to EventSource,
it might be pretty uncommon to use a relative path to the push service.
Anyhow, I think this should disappear with the parameter in the methods.
The client shouldn't know which server is used: this is part of the
user's privacy.

bryan But as with EventSource, we won't know if the service URL will be 
commonly relative, or not. EventSource itself is quite young in terms of 
adoption, and with CORS there are good reasons why the path *won't

RE: [manifest] screen sizes, Re: Review of Web Application Manifest Format and Management APIs

2012-05-27 Thread SULLIVAN, BRYAN L

Re At install time or when I am browsing apps, how does a server know my 
screen resolution? Or is this restriction imposed on by the user agent?: When 
browsing apps, the server can easily access the screen and window DOM 
attributes. When installing apps, the installer (browser, app manager, etc) can 
provide a warning to the user that the app is designed for use on larger 
screens, and may not work properly on this device.

Thanks,
Bryan Sullivan 

-Original Message-
From: Marcos Caceres [mailto:w...@marcosc.com] 
Sent: Sunday, May 27, 2012 1:35 AM
To: Anant Narayanan
Cc: SULLIVAN, BRYAN L; public-webapps@w3.org
Subject: Re: [manifest] screen sizes, Re: Review of Web Application Manifest 
Format and Management APIs



On 26 May 2012, at 18:32, Anant Narayanan an...@mozilla.com wrote:

 On 05/25/2012 09:25 AM, Marcos Caceres wrote:
 
 
 On Friday, May 25, 2012 at 4:34 PM, SULLIVAN, BRYAN L wrote:
 
 Marcos,
 
 Re I thought we had stopped the whole designing for particular screen 
 sizes, etc. a long time ago., that may be the still-closely-held goal, but 
 the reality is that designing for multiple screen sizes (and pixel 
 densities) is still far from simple. Even with all the tools that have been 
 developed in CSS and Media Queries.
 
 So if developers want to claim that they have focused their design on 
 specific form factors (and presumably tested it thoroughly on them), this 
 seems like a good thing as it allows them to be more certain that their 
 apps won't be distributed to users of devices on which they won't work well 
 (which will negatively impact the developer's reputation, use of the app, 
 appstore etc), or if distributed to such users, will be clearly identified 
 as not being designed for those devices.
 
 Like many of the things we wanted to do in widget manifest structures in 
 BONDI and WAC, if these get pulled from the plan the only fallback is 
 developer ecosystem-specific app metadata, which in the end evaporates with 
 the developer ecosystems, or never achieves widespread use or 
 interoperability. So the problem is not solved for developers by leaving 
 these things out of standards, where there is a strong use case.
 
 
 Still sounds to me like Made forinsert everyone's favorite 90's browser 
 here, and best viewed at 800x600 … and look how well that turned out. Even 
 if we don't focus on mobile devices, it seems like a silly requirement as I 
 can just adjust my browser window to whatever size I want (there is no 
 reason to believe I won't be able to do that on future mobile devices). 
 I.e., screen size and application display area are not the same thing and 
 this metadata attribute seems to assume so.
 
 The intent for the screen_size parameters is not to let the developer enforce 
 a particular screen size or resolution, but rather specify the *minimum* 
 width and height required by the app. This means that on a screen below the 
 specified size, the app will not function at all.

To make this more clear, maybe call this min_screen_size. 

 
 I will also note that it is upto the app store to interpret this field 
 however they'd like. If they do not want to disallow installs on devices that 
 don't meet the developer-specified criteria, that's fine. However, we should 
 still convey this information from the developer to the store via the 
 manifest.

At install time or when I am browsing apps, how does a server know my screen 
resolution? Or is this restriction imposed on by the user agent?

 It is unrealistic to assume that all app developers will make a responsive 
 design for all possible screen sizes. The tools aren't great and it costs 
 time and money. We added this field after we received a request from the 
 developer of a popular game that only worked on desktops, but not mobile 
 phones (due to size). They wanted to make sure users weren't able to install 
 them in places the app wasn't designed for and get a bad impression of the 
 company. I think this is really important.

I think that's fine, but as Scott pointed pointed out, user agents have a 
history of allowing users to bypass these kinds of restrictions (or users hack 
around them). I think this field can only really serve as a warning that the 
app might not work as expected.

RE: [manifest] screen sizes, Re: Review of Web Application Manifest Format and Management APIs

2012-05-27 Thread SULLIVAN, BRYAN L

OK, response inline. Below is a response to your request, unfortunately 
top-posted as I think this is an important procedural point and needs the 
visibility.

Re top-posting, I wasn't even aware of the practice or term. FYI for me it's 
the natural way to respond, easier to focus on what I want to respond to or 
what others have responded to (if they follow a similar practice). Its follows 
the natural flow of conversation, in which what the last person said (and the 
one before, etc...) does not have to be repeated by every person. Only the 
minimum necessary context should need be provided for the next comment.

To me, top-posting as you refer to it is easier than digging through emails 
with widely inconsistent methods of in-place responses (in which who said what 
can be very difficult to follow, unless you go back and reconstruct the whole 
thread, and even then it's not easy). 

If we want to mandate that all comments start with a commenter tag (e.g. 
bryan) and if breaking a previous paragraph also include a close tag 
(/bryan) then in-line commenting makes more sense to me.

I also note that the recommendation for inline commenting is a note on a WHATWG 
wiki, not a W3C convention. And even within itself seems contradictory... and 
my practice is consistent with what it recommends as Quote enough original 
text or provide an introduction yourself.

Thanks,
Bryan Sullivan 

-Original Message-
From: Marcos Caceres [mailto:w...@marcosc.com] 
Sent: Sunday, May 27, 2012 5:12 AM
To: SULLIVAN, BRYAN L
Cc: Anant Narayanan; public-webapps@w3.org
Subject: Re: [manifest] screen sizes, Re: Review of Web Application Manifest 
Format and Management APIs

On 27/05/2012 12:36, SULLIVAN, BRYAN L wrote:
 Re At install time or when I am browsing apps, how does a server know my 
 screen resolution? Or is this restriction imposed on by the user agent?: 
 When browsing apps, the server can easily access the screen and window DOM 
 attributes.
Right, but that requires some communication that is implicit in the 
spec. I'm trying to figure out what data is leaving my device and going 
to the server, and why (i.e., what is the expected life cycle model). 
There is all sorts of things that are implied going on behind the scenes 
that this spec eludes to (e.g., installation management/sync across 
devices), and it's good to get a sense of how it all comes together. If 
it's not clear in the spec, then I have a hard time seeing how multiple 
user agents will be able behave in an interoperable manner.
   When installing apps, the installer (browser, app manager, etc) can provide 
 a warning to the user that the app is designed for use on larger screens, and 
 may not work properly on this device.
Sure, but doesn't that lead to the original complaint that certain 
developers don't want their application to install at all for PR reasons?
bryan That preference to prevent installation on incompatible devices is 
reasonable, but then they likely need to control distribution, e.g. use the 
metadata (and device info) at the appstore to prevent the app from being 
offered at all, and prevent side-loading as far as possible. User agents could 
also provide a don't install incompatible apps option for users. For the 
rest, a warning will at least focus the responsibility on the user; I think 
they will be less likely to complain if given fair warning.

Ps: Bryan, can I kindly ask that you please stop top-posting on W3C 
mailing lists. It makes it hard to keep threads together. Please see:
http://wiki.whatwg.org/wiki/FAQ#Should_I_top-post_or_reply_inline.3F

 Thanks,
 Bryan Sullivan

 -Original Message-
 From: Marcos Caceres [mailto:w...@marcosc.com]
 Sent: Sunday, May 27, 2012 1:35 AM
 To: Anant Narayanan
 Cc: SULLIVAN, BRYAN L; public-webapps@w3.org
 Subject: Re: [manifest] screen sizes, Re: Review of Web Application Manifest 
 Format and Management APIs



 On 26 May 2012, at 18:32, Anant Narayanan an...@mozilla.com wrote:

 On 05/25/2012 09:25 AM, Marcos Caceres wrote:

 On Friday, May 25, 2012 at 4:34 PM, SULLIVAN, BRYAN L wrote:

 Marcos,

 Re I thought we had stopped the whole designing for particular screen 
 sizes, etc. a long time ago., that may be the still-closely-held goal, 
 but the reality is that designing for multiple screen sizes (and pixel 
 densities) is still far from simple. Even with all the tools that have 
 been developed in CSS and Media Queries.

 So if developers want to claim that they have focused their design on 
 specific form factors (and presumably tested it thoroughly on them), this 
 seems like a good thing as it allows them to be more certain that their 
 apps won't be distributed to users of devices on which they won't work 
 well (which will negatively impact the developer's reputation, use of the 
 app, appstore etc), or if distributed to such users, will be clearly 
 identified as not being designed for those devices.

 Like many of the things we wanted to do in widget manifest

RE: Push API draft uploaded

Hi Jose,

Thanks for the comments.

Re the idea is to decouple permissions from APIs: potentially for the Sysapps 
WG this will be possible, but currently in DAP and in Webapps if the Web 
security model isn't enough (e.g. same-origin and CORS), then any special 
considerations are addressed in the API specs themselves. In this case the 
ability to invoke the app (wakeup) and receive Push messages when the app is 
offline in general (as in the Mozilla proposal) goes beyond the ability of 
same-origin and CORS to ensure user protection. Thus the user is prompted at 
least once. It's not a perfect solution but at least consistent with what has 
been the approach, and usable until we get to a more robust permissions 
framework.

Re wakeup as part of an App Manifest: this does not yet apply to Web apps in 
general. It does seem useful to consider in the Web app manifest 
(https://people.mozilla.com/~anarayanan/webapps.html) as proposed to be worked 
in Webapps, but again that does not apply (or does not have to be used) for all 
Web apps. I suppose one could make the argument that if you expect to be woken 
up, the app should be installed, but I think caching also works for that (as 
described in the spec as Examples of cases in which webapps should be 
invokable).

Re distinguish between registering the interest on receiving push messages and 
receiving push messages themselves: I am following the Mozilla lead on 
registering the intent to receive messages, and also going beyond it with the 
actual reception capability, and there are separate interfaces for the two 
functions. We don't yet have a generic intent registration mechanism for use 
here (e.g. based upon the API feature URL concept previously proposed for 
Widgets and leveraged in WAC), and we may approach that again in Sysapps (TBD), 
but for now I think the APIs need to address both functions.

Re the possibility of having a queue of pending messages: the spec leaves 
this as a MAY for now: When a Push message is received, the user agent must 
deliver the message data via the onmessage handler, if possible. If delivery is 
not possible, the user agent may discard the message, or may queue it for later 
delivery.

Thanks,
Bryan Sullivan 

-Original Message-
From: JOSE MANUEL CANTERA FONSECA [mailto:j...@tid.es] 
Sent: Friday, May 25, 2012 4:36 AM
To: SULLIVAN, BRYAN L; public-webapps
Subject: Re: Push API draft uploaded

I have some comments:

I think the idea is to decouple permissions from APIs, making that part of
a Security Model, so I don't understand why we are putting here that
functionality.

Concerning wakeup, etc. I think that should not be part of the API itself
but of the App Manifest

I think we need to distinguish between registering the interest on
receiving push messages and receiving push messages themselves.

The current API does not address the possibility of having a queue of
pending messages.

best

El 24/05/12 09:14, SULLIVAN, BRYAN L bs3...@att.com escribió:

Thanks to the inestimable help of the W3C staff I am now plugged into the
mercurial mainline and have uploaded the first stab at the Push API
http://dvcs.w3.org/hg/push/raw-file/default/index.html

I incorporated Mozilla's client API ideas in
https://wiki.mozilla.org/Services/Notifications/Push/API as the
PushManager interface, and also in the PushService interface with
some additions to support a more explicit event model for received
message delivery, derived from Server-Sent Events.

A lot is still left unsaid, and I will work on examples.

I also have not addressed the server API aspect that Mozilla mentioned in
their proposal. Like a lot that is left unsaid in their client API
proposal (how does the browser determine what that magic server URL
is...?), the server API is likely related to the specific Push service
that is bound to the API. I am considering the use of Web Intents to
discover and select the Push Service provider that the user wants apps to
use, assuming that we can leave the backend details to the intent
provider. I'm not yet sure how the pieces will fit together, how much
needs to be defined, and how my earlier proposal about specific event
source selection and filtering fits into this, but it's a start.

Thanks,
Bryan Sullivan







Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

RE: [manifest] screen sizes, Re: Review of Web Application Manifest Format and Management APIs

Marcos, 

Re I thought we had stopped the whole designing for particular screen sizes, 
etc. a long time ago., that may be the still-closely-held goal, but the 
reality is that designing for multiple screen sizes (and pixel densities) is 
still far from simple. Even with all the tools that have been developed in CSS 
and Media Queries. 

So if developers want to claim that they have focused their design on specific 
form factors (and presumably tested it thoroughly on them), this seems like a 
good thing as it allows them to be more certain that their apps won't be 
distributed to users of devices on which they won't work well (which will 
negatively impact the developer's reputation, use of the app, appstore etc), or 
if distributed to such users, will be clearly identified as not being designed 
for those devices.

Like many of the things we wanted to do in widget manifest structures in BONDI 
and WAC, if these get pulled from the plan the only fallback is developer 
ecosystem-specific app metadata, which in the end evaporates with the developer 
ecosystems, or never achieves widespread use or interoperability. So the 
problem is not solved for developers by leaving these things out of standards, 
where there is a strong use case.

Thanks,
Bryan Sullivan 

-Original Message-
From: Marcos Caceres [mailto:w...@marcosc.com] 
Sent: Friday, May 25, 2012 7:43 AM
To: Anant Narayanan
Cc: public-webapps@w3.org
Subject: [manifest] screen sizes, Re: Review of Web Application Manifest Format 
and Management APIs




On Sunday, May 13, 2012 at 5:47 PM, Anant Narayanan wrote:

   screen_size: This object may contain the min_height and min_width 
   properties that describe the minimum height and width (in pixels) the 
   application needs in order to render correctly. Interpretation of these 
   values is left up to the runtime and/or app store.
  
  
  
  How does this play with CSS and media queries in particular? What's the use 
  case?
 
 These values do not interfere with runtime detection via media queries.
 The use case for these values is two-fold:
 - An app store may prevent the user from installing an app on a device
 which doesn't meet this criteria
 - A UA may prevent the user from launching an app on a device which
 doesn't meet this criteria
 
 The primary goal in both cases is to let the developer declare what
 screen sizes their app is known to work correctly.

The above cases seems very anti-web IMHO. I thought we had stopped the whole 
designing for particular screen sizes, etc. a long time ago. I feel it would be 
a shame to codify this in a spec.

-- 
Marcos Caceres

RE: [manifest] screen sizes, Re: Review of Web Application Manifest Format and Management APIs

Perhaps this particular issue then (the need to convey information about 
intended usage of an app, or preferred device characteristics), especially 
designing for a diverse set of devices and screen characteristics (mobile 
phones up to building-side billboards), should be something that we encourage 
developer input on through the community group process. My sense is that it's a 
bigger problem than it seems, and that by just saying apps should work on any 
device or apps should not be tailored to specific device characteristics 
thus we don't need such metadata in manifests, we are doing developers a 
disservice. It's much more complicated than that, and I believe developers *do* 
commonly focus on particular device segments when designing Webapps.

Thanks,
Bryan Sullivan 

-Original Message-
From: Scott Wilson [mailto:scott.bradley.wil...@gmail.com] 
Sent: Friday, May 25, 2012 12:59 PM
To: Marcos Caceres
Cc: SULLIVAN, BRYAN L; Anant Narayanan; public-webapps WG; 
public-webappst...@w3.org
Subject: Re: [manifest] screen sizes, Re: Review of Web Application Manifest 
Format and Management APIs

On 25 May 2012, at 17:25, Marcos Caceres wrote:

 
 
 On Friday, May 25, 2012 at 4:34 PM, SULLIVAN, BRYAN L wrote:
 
 Marcos,  
 
 Re I thought we had stopped the whole designing for particular screen 
 sizes, etc. a long time ago., that may be the still-closely-held goal, but 
 the reality is that designing for multiple screen sizes (and pixel 
 densities) is still far from simple. Even with all the tools that have been 
 developed in CSS and Media Queries.  
 
 So if developers want to claim that they have focused their design on 
 specific form factors (and presumably tested it thoroughly on them), this 
 seems like a good thing as it allows them to be more certain that their apps 
 won't be distributed to users of devices on which they won't work well 
 (which will negatively impact the developer's reputation, use of the app, 
 appstore etc), or if distributed to such users, will be clearly identified 
 as not being designed for those devices.

I think there is a problem here that we can get very mobile and tablet focussed 
- some of our widgets are also designed with interactive whiteboards and TVs in 
mind which may throw off selections based on things like screen size and pixel 
density. 

I can see users ending up doing the whole spoof the user-agent string again 
here, as when sites started showing your browser is not supported when you 
viewed them with something the developer hadn't considered. 

Perhaps at the store level it would be nice to have some assertions of 
platforms tested by the developer, but that would be something different really 
(perhaps something for the web app stores CG to look at).

 
 Like many of the things we wanted to do in widget manifest structures in 
 BONDI and WAC, if these get pulled from the plan the only fallback is 
 developer ecosystem-specific app metadata, which in the end evaporates with 
 the developer ecosystems, or never achieves widespread use or 
 interoperability. So the problem is not solved for developers by leaving 
 these things out of standards, where there is a strong use case.
 
 
 Still sounds to me like Made for insert everyone's favorite 90's browser 
 here, and best viewed at 800x600 ... and look how well that turned out. 
 Even if we don't focus on mobile devices, it seems like a silly requirement 
 as I can just adjust my browser window to whatever size I want (there is no 
 reason to believe I won't be able to do that on future mobile devices). I.e., 
 screen size and application display area are not the same thing and this 
 metadata attribute seems to assume so.
 
 --  
 Marcos Caceres

RE: Push API draft uploaded

Thanks for the comments. Some responses added as bryan

Thanks,
Bryan Sullivan

-Original Message-
From: Mounir Lamouri [mailto:mou...@lamouri.fr] 
Sent: Friday, May 25, 2012 3:17 PM
To: public-webapps@w3.org
Subject: Re: Push API draft uploaded

On 05/24/2012 09:14 AM, SULLIVAN, BRYAN L wrote:
 Thanks to the inestimable help of the W3C staff I am now plugged into the 
 mercurial mainline and have uploaded the first stab at the Push API
 http://dvcs.w3.org/hg/push/raw-file/default/index.html

 I incorporated Mozilla's client API ideas in 
 https://wiki.mozilla.org/Serices/Notifications/Push/API as the PushManager 
 interface, and also in the PushService interface with some additions to 
 support a more explicit event model for received message delivery, derived 
 from Server-Sent Events.

 A lot is still left unsaid, and I will work on examples.

 I also have not addressed the server API aspect that Mozilla mentioned in 
 their proposal. Like a lot that is left unsaid in their client API proposal 
 (how does the browser determine what that magic server URL is...?), the 
 server API is likely related to the specific Push service that is bound to 
 the API. I am considering the use of Web Intents to discover and select the 
 Push Service provider that the user wants apps to use, assuming that we can 
 leave the backend details to the intent provider. I'm not yet sure how the 
 pieces will fit together, how much needs to be defined, and how my earlier 
 proposal about specific event source selection and filtering fits into this, 
 but it's a start.

Hi,

I have a few random comments:

* As far as I understand it, |requestRemotePermission| and
|checkRemotePermission| could be one single method which could be named
something like |getPushServiceUrl|. The only difference between those
two methods is the permission asking part but that should stay as a UA
decision. Given that the method is anyway asynchronous, the UA can do
whatever wanted before sending a result. Showing a permission prompt
could be one of those.

bryan I agree that these methods could collapse into one. But as this 
interface was based upon the Mozilla proposal 
(https://wiki.mozilla.org/Services/Notifications/Push/API) I would like to get 
the author's view on the potential to collapse the two methods into one.

* I wonder if it is really useful to have clients requesting a specific
Push service. I totally understand why a user would request to use his
preferred Push service but that is part of the UA. I would tend to think
we should not add that parameter until it's proven to be needed by some
consumer of the API. Adding it would be simple; removing it might not be
an option. Also, allowing a website to chose the Push service might
break the entire idea of decentralization here: you might end up with
most websites requesting to use push.popularservice.com.

bryan If a service is effective and thus popular, why shouldn't it be 
accessible to developers? Rather than break decentralization, this flexibility 
enables it IMO, so I think there is a misunderstanding somewhere. To enable 
some degree of Push service (and thus service provider) flexibility, I have 
also proposed that we could use Web Intents as a way to allow the user to 
select the service provider, but if the app has particular requirements (e.g. 
security or delivery methods/bearers), I see no reason why we should obfuscate 
the developer intent by making the user play the match maker. The requested 
service URL also provides means to negotiate additional functionality/options 
between the app and the Push service directly e.g. as above (e.g. security, 
delivery methods/bearers, application characteristics, ...).

* I'm not sure why you have a |requestUrl| attribute in PushService. Do
you have any use case for that?

bryan The use case is that an app can have multiple Push service requests 
active at a time, with different URLs. In order to be able to associate each 
PushService object with a specific set of options or services for example, it 
needs to know what URL was used when the PushService object was created. The 
intent is similar to that of EventSource, which has the url attribute for a 
similar purpose (at least that is how I have used it). And since the 
checkRemotePermission() method needs to verify the permission for the same URL, 
it is better to have the resolved form of the URL available as an attribute, so 
that it's easy to call the checkRemotePermission() method for the right URL (as 
the absolute URL may have changed since the original resolution).

* |readyState| should be a DOMString.

bryan The jury is out on this, AFAICT. It's a short in EventSource and XHR. I 
was following their lead.

* I guess the idea of |onmessage| is that the PushService instance will
get an event when the backend will push a notification to the webapp.
However, I wonder how you do handle the situation when the application
is actually not being ran. Or should we wait

Push API draft uploaded

Thanks to the inestimable help of the W3C staff I am now plugged into the 
mercurial mainline and have uploaded the first stab at the Push API
http://dvcs.w3.org/hg/push/raw-file/default/index.html

I incorporated Mozilla's client API ideas in 
https://wiki.mozilla.org/Services/Notifications/Push/API as the PushManager 
interface, and also in the PushService interface with some additions to 
support a more explicit event model for received message delivery, derived from 
Server-Sent Events.

A lot is still left unsaid, and I will work on examples.

I also have not addressed the server API aspect that Mozilla mentioned in their 
proposal. Like a lot that is left unsaid in their client API proposal (how does 
the browser determine what that magic server URL is...?), the server API is 
likely related to the specific Push service that is bound to the API. I am 
considering the use of Web Intents to discover and select the Push Service 
provider that the user wants apps to use, assuming that we can leave the 
backend details to the intent provider. I'm not yet sure how the pieces will 
fit together, how much needs to be defined, and how my earlier proposal about 
specific event source selection and filtering fits into this, but it's a start.

Thanks,
Bryan Sullivan

RE: Push API draft uploaded

Thanks for the comments. I updated the spec:
- define what happens when url is omitted
- remove [NoInterfaceObject]
- define readyState as a unsigned short (that was what was meant in the first 
place)
- fix cut/paste errors

I still have to find the source of resolve a url as that's a function I 
borrowed from EventSource.

Latest version is at http://dvcs.w3.org/hg/push/raw-file/default/index.htm 

Thanks,
Bryan Sullivan

-Original Message-
From: Ms2ger [mailto:ms2...@gmail.com] 
Sent: Thursday, May 24, 2012 12:33 AM
To: SULLIVAN, BRYAN L
Cc: public-webapps
Subject: Re: Push API draft uploaded

On 05/24/2012 09:14 AM, SULLIVAN, BRYAN L wrote:
 Thanks to the inestimable help of the W3C staff I am now plugged into
 the mercurial mainline and have uploaded the first stab at the Push
 API
  http://dvcs.w3.org/hg/push/raw-file/default/index.html

A couple of notes on the WebIDL:

* PushManager has
   |PushService requestRemotePermission ([Optional] DOMString url);|,
   should be ... (optional DOMString url), though the spec doesn't
   appear to define what happens when url is omitted; same for
   checkRemotePermission.
* There does not appear to be a need to make PushManager and PushService
   use [NoInterfaceObject], so please remove that.
* PushService.readyState is a DOMString, but the spec defines it to
   return the unsigned short constants CONNECTING/OPEN/CLOSED. Please
   get rid of the constants.

The requestUrl attribute must return the absolute URL where the webapp 
server can send Push service messages to this webapp. should probably 
refer to |serviceUrl|, not |requestUrl|.

A reference to DOM4 for the DOMError interface should probably be added. 
Also, the resolve a url cross-reference is broken.

HTH
Ms2ger

RE: Push API draft uploaded

Sorry, cut  paste error: the spec is at: 
http://dvcs.w3.org/hg/push/raw-file/default/index.html 

Thanks,
Bryan Sullivan 

-Original Message-
From: SULLIVAN, BRYAN L 
Sent: Thursday, May 24, 2012 6:02 AM
To: 'Ms2ger'
Cc: public-webapps
Subject: RE: Push API draft uploaded

Thanks for the comments. I updated the spec:
- define what happens when url is omitted
- remove [NoInterfaceObject]
- define readyState as a unsigned short (that was what was meant in the first 
place)
- fix cut/paste errors

I still have to find the source of resolve a url as that's a function I 
borrowed from EventSource.

Latest version is at http://dvcs.w3.org/hg/push/raw-file/default/index.htm 

Thanks,
Bryan Sullivan

-Original Message-
From: Ms2ger [mailto:ms2...@gmail.com] 
Sent: Thursday, May 24, 2012 12:33 AM
To: SULLIVAN, BRYAN L
Cc: public-webapps
Subject: Re: Push API draft uploaded

On 05/24/2012 09:14 AM, SULLIVAN, BRYAN L wrote:
 Thanks to the inestimable help of the W3C staff I am now plugged into
 the mercurial mainline and have uploaded the first stab at the Push
 API
  http://dvcs.w3.org/hg/push/raw-file/default/index.html

A couple of notes on the WebIDL:

* PushManager has
   |PushService requestRemotePermission ([Optional] DOMString url);|,
   should be ... (optional DOMString url), though the spec doesn't
   appear to define what happens when url is omitted; same for
   checkRemotePermission.
* There does not appear to be a need to make PushManager and PushService
   use [NoInterfaceObject], so please remove that.
* PushService.readyState is a DOMString, but the spec defines it to
   return the unsigned short constants CONNECTING/OPEN/CLOSED. Please
   get rid of the constants.

The requestUrl attribute must return the absolute URL where the webapp 
server can send Push service messages to this webapp. should probably 
refer to |serviceUrl|, not |requestUrl|.

A reference to DOM4 for the DOMError interface should probably be added. 
Also, the resolve a url cross-reference is broken.

HTH
Ms2ger

RE: Push API draft uploaded

OK, I corrected the [NoInterfaceObject] (I hope), and referenced HTML5 for 
resolving a URL.

The numeric readyState was borrowed from EventSource. I will look at the 
thread, but I think this is something that I will just align with the consensus 
in the group once determined. I don't have a strong opinion either way.

Latest version is at http://dvcs.w3.org/hg/push/raw-file/default/index.html 

Thanks,
Bryan Sullivan 

-Original Message-
From: Ms2ger [mailto:ms2...@gmail.com] 
Sent: Thursday, May 24, 2012 6:37 AM
To: SULLIVAN, BRYAN L
Cc: public-webapps
Subject: Re: Push API draft uploaded

Hi Brian,

On 05/24/2012 03:02 PM, SULLIVAN, BRYAN L wrote:
 Thanks for the comments. I updated the spec:
 - define what happens when url is omitted
 - remove [NoInterfaceObject]
 - define readyState as a unsigned short (that was what was meant in the first 
 place)
 - fix cut/paste errors

 I still have to find the source of resolve a url as that's a function I 
 borrowed from EventSource.

 Latest version is at http://dvcs.w3.org/hg/push/raw-file/default/index.html

Thanks for the update. resolve a url is defined in HTML; see 
http://www.whatwg.org/html/#resolving-urls.

As for a numeric readyState, please have a look at the discussion at 
http://lists.w3.org/Archives/Public/public-script-coord/2012JanMar/0166.html.

Finally, it appears that you removed [NoInterfaceObject] from 
NavigatorPush (where I believe it was correct), rather than from 
PushService.

HTH
Ms2ger

Re: Push API draft uploaded