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

On Tue, Dec 9, 2014 at 6:39 AM, Mike West <mkwst@google.com> wrote:

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

​I think there should be explicit consideration for the case where a new
feature is widely seen as a replacement for an old. perhaps different,
feature. Especially where there is a desire to remove the old feature
altogether. The existing users of such a legacy feature should be factored
into this discussion in just the same way as the existing users of features
which match the geo-location example.

EME as a replacement for <object> is one example.

I'm still not sure the reference to EME is Section 3, item 4, is correct.
If the intention in that bullet is to capture anything that could expose
temporary identifiers then it would be clearer if you included Web Storage
/ IndexedDB as well. If the intention is specifically to capture things
which expose identifiers that cannot easily be cleared by the user, then
EME is not an example since it is now *normatively* required that
identifiers exposed by EME *can* be easily cleared by the user.

...Mark



>
> 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.)
>