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

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

> On Tue, Dec 9, 2014 at 5:54 PM, Mark Watson <watsonm@netflix.com> wrote:
>>
>> ​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.
>>
>
> What would you like the spec to say about these kinds of features?
>

I think the considerations should be similar to those for pre-existing
features (if the objective is to deprecate or restrict the old feature).


>
> My initial feeling is that there's no relevant difference between a new
> feature introduced because it's independently awesome, and a new feature
> which is introduced in order to replace an old feature.
>

​The relevant difference is that *if it's an objective to deprecate or
restrict the legacy feature*, then barriers to the adoption of ​the new
feature also slow down deprecation / restriction of the old one. No such
consideration exists for a brand new feature.

If, on the other hand, there is no desire to deprecate or restrict the old
feature, then I agree, there is no relevant difference.

...Mark


>
>
>> 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.
>>
>
> I think the terms I chose there are misleading: to be clear, I see three
> categories of identifiers that should be discussed:
>
> * EME (and cookies, and IDB, and etc) expose an identification mechanism
> that sticks around until the user takes explicit action to remove the
> identifier.
>
> * Session storage clears itself within some reasonable period, and without
> explicit user action (in theory).
>
> * Device-level identifiers are not clearable.
>
> I'll attempt to clarify the intent.
>
> --
> 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.)
>