Re: [jetty-dev] MIME type for .otf file extension

[Basil Crow <me@xxxxxxxxxxxxx>]

On Wed, Aug 14, 2024 at 2:06 PM Joakim Erdfelt <joakim.erdfelt@xxxxxxxxx> wrote:
> The one that doesn't break existing installations.

"Compatibility matters" is a strong value of my community as well (as
documented explicitly in
https://www.jenkins.io/project/governance/#compatibility-matters and
our contributing guide). A commitment to compatibility is a source of
strength for a mature software project such as Jetty, and I stand
behind this commitment.

Yet this is not a black and white matter, either. If the Jetty project
believed in never breaking compatibility in any way, shape, or form,
then why were https://jetty.org/docs/jetty/12/programming-guide/migration/94-to-10.html
and https://jetty.org/docs/jetty/12/programming-guide/migration/11-to-12.html
necessary, and why was it necessary to update the documentation for
https://github.com/jetty/jetty.project/pull/10077 in
https://github.com/jetty/jetty.project/issues/11761?

This is not just about migrations for programmers, either. The Jetty
developers have recently changed default behavior for end users in
https://github.com/jetty/jetty.project/pull/11019#discussion_r1416294734
which has broken one of our use cases. Based on this evidence, I
simply cannot accept your black and white statement that the Jetty
project never breaks existing installations. Our existing installation
has been broken quite recently.

> We don't want to break existing installations.

The truth is that compatibility is a more nuanced matter than your
black and white statement. The Jetty core team can and does take
calculated risks that may (or certainly will) break existing
installations in some way, shape, or form; however, these are deemed
acceptable risks (or costs) given some particular benefit.

> This suggestion is a solution that will fit with not breaking people, and allowing folks like yourself to have a behavior that you seem to want (apache httpd parity).

Again, the Jetty project can and does make breaking changes on a
case-by-case basis, and I do not specifically want parity with Apache
httpd. I simply want Jetty to work out-of-the box for the majority of
people without requiring custom configuration.

> The real world for the web has all kinds of odd cases that people feel are normal and justified.
> When we dropped `;charset=utf-8` from the `Content-Type: application/json` we had broken thousands of installations and got an earful. (we were just following the json spec, RFC8259 and RFC7159)
> That change was made for exactly the same reasoning you are providing ... "the most prevalent use cases of the Web platform in 2024", yet we broke people.
> Hence, we don't want to break them again.

Do you think thousands of existing installations are relying on
OpenDocument Formula Templates, a feature to which the last reference
we can find is from 2008? These examples are not at all comparable in
scope.

>> In 2008, OpenType font embedding on web pages was uncommon, so this
>> decision makes sense historically. But in 2024, when the font
>> embedding use case for the Web platform is common enough to be
>> documented at https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face
>> and other sources (while the OpenDocument use case is not documented
>> at https://developer.mozilla.org), wouldn't it make more sense to
>> prefer the font embedding use case?
>
> This extension is very much still in use in todays real world.

This is still not an answer to my question; in any case, so was the
behavior in https://github.com/jetty/jetty.project/pull/11019#discussion_r1416294734
that we were relying on. I am not suggesting that the PR be reverted;
we have adapted and moved on.

The question is not whether or not any breaking changes are ever
acceptable, but rather whether or not the risk is acceptable in this
case. Given the far riskier examples I have cited above where breakage
occurred (and was not reverted), do you have evidence that this
particular change would incur undue risk? Even if you do, couldn't the
change easily be reverted in that unlikely scenario?

Best regards,
Basil