5 ms·

> Examples, image editors need to load new formats Alternatively, they could be designed to support plugins.

creshal 5y ago
Someone still needs to write those, and you'd need to be a psychic to succeed in making an immutable API that can handle all possible future requirements. E.g., up until a while back, 32-bit ARGB as exchange format would've been sufficient, but is now insufficient to handle 10 bit channels and/or stuff like HDR. What if we get a standard for 3D images? It gets worse if you want to handle animated images as well, whatever exchange format you specify will break once a decade at least. And god forbid someone tries DRM for images again…
- selfhoster11 5y ago
  Amiga did it. We can do it again. Besides, such an API is a slow-moving target, so still better than status quo.
  - BrightGlow 5y ago
    Are we thinking about the same thing? Amiga did not have a perfectly future-proof API. Such an invention would be the holy grail of API design.
    - selfhoster11 5y ago
      Some future proofing is better than none, right?
  - creshal 5y ago
    The status quo is the continued existence of IrfanView, which is probably as close as it gets to the ideal. Hasn't changed much since the 1990s, and looks like it, but supports about everything via plugins.
    - BrightGlow 5y ago
      IrfanView is updated constantly though.
      - selfhoster11 5y ago
        Yes, but the idea is that even if the original author dies, people can still keep using the last release of the application, but independently write new plugins to interpret new image formats that come out in the future. Winamp has a similar property. If in 2030 FLAC is replaced by some fancy neural-network based lossless encoder, it can still read the files and play them without touching the core of the application, because all that's needed is a single plugin.
        BrightGlow 5y ago
        Well IrfanView is open source, so if the original author dies I would expect someone else to pick it up. Your description might help with one specific area (compression algorithms) but there are numerous other areas where you can't just use a plugin.
joshuamorton 5y ago
This works, until something about the image violate your expectation. To use the image example, say you have an image editor that uses the common assumption that a pixel is a 3-byte item, with 255 possible values. Lots of stuff worked this way, its sort of a base assumption around which you have to build all your other stuff. Violating it requires you to like change sizes everywhere, which may mean performance of your fancy vectorized algorithm plummets somewhere. Anyway, lots of stuff follows this 8-bit-per-channel api. Until you use RAW images or any number of higher color depth . Then you need 12 or 16 or 24 or 32 (or more) bits per channel.
kbenson 5y ago
At the point your text processing utility that was ASCII capably gets a plugin to support UTF-8 or UTF-16 you've made so much of the core modular that it no longer serves the benefit your proposed them for. Replacing core plugins of a program that provide the actual usefulness of it is no better than just upgrading the program. Modularity can be useful, but there's always a core, and sometimes the core needs a change. And that's before we even get into security issues. Sometimes entirely new classes of security problems are discovered, and if they weren't known at the time of writing, how were the authors supposed to guard against them? How much can we fault browsers for not guarding against spectre/meltdown when they were first written and released?
GrumpyNl 5y ago
Thats a update to.

Someone still needs to write those, and you'd need to be a psychic to succeed in making an immutable API that can handle all possible future requirements. E.g., up until a while back, 32-bit ARGB as exchange format would've been sufficient, but is now insufficient to handle 10 bit channels and/or stuff like HDR. What if we get a standard for 3D images? It gets worse if you want to handle animated images as well, whatever exchange format you specify will break once a decade at least. And god forbid someone tries DRM for images again…

selfhoster11 5y ago
Amiga did it. We can do it again. Besides, such an API is a slow-moving target, so still better than status quo.
- BrightGlow 5y ago
  Are we thinking about the same thing? Amiga did not have a perfectly future-proof API. Such an invention would be the holy grail of API design.
  - selfhoster11 5y ago
    Some future proofing is better than none, right?
- creshal 5y ago
  The status quo is the continued existence of IrfanView, which is probably as close as it gets to the ideal. Hasn't changed much since the 1990s, and looks like it, but supports about everything via plugins.
  - BrightGlow 5y ago
    IrfanView is updated constantly though.
    - selfhoster11 5y ago
      Yes, but the idea is that even if the original author dies, people can still keep using the last release of the application, but independently write new plugins to interpret new image formats that come out in the future. Winamp has a similar property. If in 2030 FLAC is replaced by some fancy neural-network based lossless encoder, it can still read the files and play them without touching the core of the application, because all that's needed is a single plugin.
      - BrightGlow 5y ago
        Well IrfanView is open source, so if the original author dies I would expect someone else to pick it up. Your description might help with one specific area (compression algorithms) but there are numerous other areas where you can't just use a plugin.

joshuamorton 5y ago

This works, until something about the image violate your expectation. To use the image example, say you have an image editor that uses the common assumption that a pixel is a 3-byte item, with 255 possible values. Lots of stuff worked this way, its sort of a base assumption around which you have to build all your other stuff. Violating it requires you to like change sizes everywhere, which may mean performance of your fancy vectorized algorithm plummets somewhere. Anyway, lots of stuff follows this 8-bit-per-channel api. Until you use RAW images or any number of higher color depth . Then you need 12 or 16 or 24 or 32 (or more) bits per channel.

kbenson 5y ago

At the point your text processing utility that was ASCII capably gets a plugin to support UTF-8 or UTF-16 you've made so much of the core modular that it no longer serves the benefit your proposed them for. Replacing core plugins of a program that provide the actual usefulness of it is no better than just upgrading the program. Modularity can be useful, but there's always a core, and sometimes the core needs a change. And that's before we even get into security issues. Sometimes entirely new classes of security problems are discovered, and if they weren't known at the time of writing, how were the authors supposed to guard against them? How much can we fault browsers for not guarding against spectre/meltdown when they were first written and released?

GrumpyNl 5y ago

Thats a update to.