Intent to Undeprecate and Retain: PPAPI (Pepper) WebSocket

[Adam Rice]

# Primary eng emails

ri...@chromium.org, yhi...@chromium.org

# Summary

In https://groups.google.com/a/chromium.org/d/msg/blink-dev/3NYHaxhRs14/XOdUJBvHAwAJ I proposed removing the pp::WebSocket PPAPI. Unfortunately an active user of the API has been found.

# Motivation

There are existing users whose workflows would be broken by removing the API. Although it is possible to emulate the API using pp::Instance::PostMessage(), as the app in question is moving off PPAPI anyway it seems unfair to force a lot of extra work on the legacy implementation.

Similarly, it is not worth my team investing in implementing an emulation of the API as it would probably cost more than continuing to maintain the pp::WebSocket implementation for the time being.

We have taken into account three types of cost associated with carrying the pp::WebSocket code:

1. Day-to-day maintenance. This is small but non-zero.
2. Opportunity cost, ie. the improvements we could make if we simplified the code by removing pp::WebSocket.
3. Unpredictable one-time costs. Examples would be security emergencies or legacy IPC removal.

The one-time costs are the most worrying, and we have to gamble that they either won't come up or won't be too time-consuming if they do.

In conclusion, with new information the scales have swung so that the small benefit from keeping the API outweighs the small cost.

The original arguments for deprecation still apply, and we hope there will be another opportunity to remove it once known users have moved off.

# Interoperability and Compatibility Risk

Retaining the API carries the risk of more adoption. However, given the general move away from PNaCl this is probably unlikely.

[Daniel Bratell]

That is always the risk in a deprecation/removal process and it's good that you caught this before anyone was hurt. I hope we'll get another shot eventually.

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC_ixdyjm99Sx%3DqehiY_%3DaZFYpQOm%2BhBjYFbt-wfc5ETbchUnA%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Yoav Weiss]

Thanks for getting back to us with data on this particular removal and the breakage it would cause.

The process is not very clear on "un-deprecations" and how many LGTMs they require. From my perspective, it would be weird for us to force someone to go ahead with removals they don't feel comfortable with.

LGTM1 to un-deprecate.

You received this message because you are subscribed to the Google Groups "blink-network-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-network-...@chromium.org.
To post to this group, send email to blink-ne...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-network-dev/op.zva6akrcrbppqq%40cicero2.linkoping.osa.

[Daniel Bratell]

Not sure this (basically) non-action requires api owner approval, but have my LGTM2.

/Daniel

[Rick Byers]

I assume the removal never got to 100% of stable, right? If so, then this is just an aborted deprecation/removal which (sadly is not terribly uncommon). The standard process is for engineers to just apply their judgement (feel free to ask advice here or blink-api-owners-discuss if you like) - no approvals required.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zvcpokblrbppqq%40cicero2.linkoping.osa.

[Adam Rice]

The deprecation only got as far as adding a console message. So undeprecating just means removing that message.