Re: RfC: Service Workers

[Arthur Barstow]

On 9/23/15 1:46 PM, Phillips, Addison wrote:

Could you better define what "soon" means? More specifically, do you have a 
deadline for comments? I don't see any dates in the thread below.


I think four weeks is the `normal` expectation for `wide reviews`. 
However, the Editors and some active participants are having a related 
meeting during the TPAC 2015 meeting week so I think you should consider 
October 25 as the target comment date. If that date won't work for you, 
please let me know.


-Thanks, AB

[webapps] spec title editorial nit [I18N-ISSUE-433]

[Phillips, Addison]

Dear webapps,

This note is to forward a minor comment from the I18N WG about your document 
"Manifest for web applications" [1] that we missed forwarding previously.

Our comment is editorial in nature:

--
The title of the specification is "Manifest for web application". Should this 
be "Manifest for a Web application"?
--

Thanks (for I18N),

[1] http://www.w3.org/TR/2015/WD-appmanifest-20150212/
[2] https://www.w3.org/International/track/issues/433

Addison Phillips
Principal SDE, I18N Architect (Amazon)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

Re: Directory Upload

[Joshua Bell]

Thanks for the status update, Ali! And kudos for the transparency around
your plans for the prefixed APIs.

Re: the new directory upload proposal [1]

It looks like there's some recent discussion [2] by Moz folks about moving
forward with implementation. On the Chrome side, we're definitely eager to
hear about implementer experience and developer feedback on the proposed
API. We'd love to start the work to deprecate Chrome's prefixed APIs once
we've got a good path forward charted.

For those who are looking to check some boxes: you can cite this as
"positive signals" from Chrome, although we have no commitment to implement
at this time.

[1] https://wicg.github.io/directory-upload/proposal.html
[2]
https://groups.google.com/forum/#!msg/mozilla.dev.platform/Q3BLd4Cwj6Q/HYwoASlJBgAJ

On Thu, Sep 3, 2015 at 12:01 PM, Ali Alabbas  wrote:

> Hello WebApps WG and Incubator CG members,
>
> As you may know, we (Microsoft) have been collaborating with Mozilla on
> evolving the new directory upload proposal [1]. It has recently been added
> to the Incubator Community Group and we are looking forward to have
> everyone get involved with providing feedback on this initial proposal. If
> you haven't already made a first-pass read of the spec, I invite you to
> take some time to do that as it is a relatively short document that we are
> trying to get some more eyes on.
>
> As we wait for the spec to stabilize, and to solve the existing interop
> gap with Chrome with regards to directory uploads, we are implementing the
> webkitRelativePath property for the File interface and webkitdirectory
> attribute for the input tag [2]. This allows sites to show a directory
> picker and to identify the relative file structure of the directory a user
> selects.
>
> Supporting webkit-prefixed properties is not an endorsement of the old way
> of doing it - it is an interop realization. For this reason, we will
> consider the webkit-prefixed API as deprecated in Microsoft Edge (as we do
> with other webkit-prefixed APIs we support for compatibility). The old API
> is synchronous and doesn't provide a natural way of traversing directories.
> That is why we are working closely with Mozilla and encouraging everyone in
> the community to look into the directory upload proposal and to provide
> feedback.
>
> Thank you,
> Ali
>
> [1] https://wicg.github.io/directory-upload/proposal.html
> [2]
> https://dev.modern.ie/platform/status/webkitdirectoryandwebkitrelativepath
> [3] https://dev.modern.ie/platform/status/directoryupload/
>
>
>

RE: RfC: Service Workers

[Phillips, Addison]

Hello Art,

Could you better define what "soon" means? More specifically, do you have a 
deadline for comments? I don't see any dates in the thread below.

Thanks,

Addison Phillips
Principal SDE, I18N Architect (Amazon)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

> -Original Message-
> From: Arthur Barstow [mailto:art.bars...@gmail.com]
> Sent: Monday, September 21, 2015 5:27 AM
> To: public-webapps
> Subject: Re: RfC: Service Workers
> 
> Please use the Version 1 branch for this review:
> 
> 
> On 9/21/15 7:27 AM, Arthur Barstow wrote:
> > [ Bcc: TAG (www-tag), WebAppSec WG (public-webapsec), Mobile IG
> > (public-web-mobile), W3C Chairs (chairs),  Review Announce list
> > (public-review-announce), Geolocation WG (public-geolocation) ]
> >
> > The Editors and active contributors of Service Workers intend to
> > publish a Candidate Recommendation soon (details below). Consequently,
> > this is a Request for Comments by the WebApps group to seek wide
> > review of the latest version of the spec:
> >
> > 
> >
> > The open issues for Version 1, and the spec's version history are [1]
> > and [2], respectively.
> >
> > If you have any comments, we prefer you submit them as Github issues
> > [3]; otherwise, please send your comments to the public-webapps list
> > [4] using a Subject: prefix of "[serviceworkers]".
> >
> > -Thanks, AB
> >
> > [1]
> >
>  > issue+milestone%3A%22Version+1%22>
> > [2] 
> > [3] 
> > [4] 
> >
> >
> > On 9/18/15 2:22 AM, Jungkee Song wrote:
> >> Hi all,
> >>
> >> We editors are happy to announce that we make a new branch for
> >> Service Workers 1 today [1].
> >>
> >> Thanks to all the contributions, Service Workers 1 now covers the
> >> fundamental model and the associated APIs to support offline-first
> >> and background processing requirements. The features in this version
> >> include:
> >>   - Register/Update/Unregister of a service worker registration
> >>   - Handle fetch events
> >>   - Fetch and Cache resources
> >>   - Manage service worker clients
> >>   - Communicate between a client and a service worker
> >>   - Define interfaces and algorithms for extensions (Push,
> >> Notification,
> >> etc.)
> >> ([2] is the remaining issues for this version in the github issue
> >> tracker.)
> >>
> >> On top of the above work, the contributors are now ready to continue
> >> with the discussions about new features including foreign fetch [3],
> >> fetch event's request's client, header-based installation,
> >> kill-switch, and so forth. These efforts will be put in Service
> >> Workers Nightly [4] which is just a new name for the original ED
> >> branch.
> >>
> >> We are planning to publish a CR based on Service Workers 1 soon
> >> during which we would like to focus on stabilizing the features (bug
> >> fix) and resolving compatibility issues among multiple
> >> implementations.
> >>
> >> For editors,
> >> Jungkee
> >>
> >>
> >> [1]
> >> https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/
> >> [2]
> >>
> https://github.com/slightlyoff/ServiceWorker/issues?q=is%3Aopen+is%3A
> >> issue+m
> >>
> >> ilestone%3A%22Version+1%22
> >> [3] https://github.com/slightlyoff/ServiceWorker/issues/684
> >> [4] https://slightlyoff.github.io/ServiceWorker/spec/service_worker/
> >>
> >>
> >> --
> >> Jungkee Song
> >> Samsung Electronics
> >
>