[POWER] New vs Legacy functionality (Re: "Requirements for Powerful Features" strawman.)

On Sun, Nov 23, 2014 at 4:53 AM, Nottingham, Mark <mnotting@akamai.com>
wrote:

>
> > On 22 Nov 2014, at 4:05 am, Mark Watson <watsonm@netflix.com> wrote:
> >
> > Mark (Nottingham) noted that we need to distinguish between "new"
> features and features whose historical context created decisions that are
> suboptimal today. I'll certainly be adding text to the doc to make a path
> forward for those types of APIs more clear.
> >
> > ​There's a distinction between entirely new functionality and new
> replacements for to-be-deprecated, but widely used, functionality.
> Completely new functionality has no existing users (sites) so you have a
> true "green field" situation (e.g. Service Workers). If you are trying to
> replace some existing widely-used legacy functionality, the situation is
> different, since too many barriers in the path of the new thing may just
> lead people to stick with the legacy solution longer.
>
> Yes; see:
>
> https://gist.github.com/mnot/38df717849b775eec3a4/550e9adc5791786ca1c8a0ade72712c466ef6978#adapting-existing-specifications
> … for what I was thinking.
>

I took a stab at this in
https://w3c.github.io/webappsec/specs/powerfulfeatures/#restrictions.
Feedback?

CCing public-geolocation@, as I've used that API as an explicit example of
something that would fall into this category. Does the strawman deprecation
plan make sense?

-mike

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)