> There is a fundamental difference in that you can drop in a new datatype without any program like ffmpeg or gstreamer having to learn new formats.
It's not an interesting or useful difference. The thing Datatypes lets you do is pointlessly spell things differently. Once you spot that you ask yourself, "Why am I doing this?" and the answer is only that you need to interoperate with other people who hadn't settled on one way to spell things so the best route forward is consolidation.
Most applications gain nothing from having, say, yet another mediocre bitmap graphics format. You just made your system more complicated without any improvements whatsoever. Clearly we should agree to just stop doing this. And we did.
> Gimp doesn't
Actually Gimp does. Gimp's file format handling is all via plug-ins. As with ImageMagick in this context maybe you actually needed to rescue crappy 1980s files you found on a floppy disk or whatever. But this helps us see what's going on - because Gimp's image file format handling is only for import and export of necessity Gimp itself is richer than any of these formats. Its native XCF format reflects a superset of the features you can care about.
But anything Gimp's native images can't do, you can't "add" using these plug-ins. The SVG plug-in for example can't magically make Gimp understand vector images, it just has to render the vector image as pixels because that's all Gimp understands.
So in the end any innovation is rendered pointless by this abstraction, the only way for an innovative idea to flourish is to sidestep a "datatypes"-like abstraction altogether.
> actually unify around using a specific standard.
You've almost understood. Instead of adding a layer of abstraction, and then unifying around this unnecessary layer, we instead chose to just use a specific standard format. The problem you're intent on solving vanished.
Didn't you ever wonder why Datatypes seemed so brilliant for image files, and kinda sorta OK for music, and then basically of no value at all for most other file formats? It's because there really were sixty different crappy pixmap formats that were completely interchangeable and half a dozen PCM audio formats likewise. But that's not what happened in other domains, because it's pointless.
> But anything Gimp's native images can't do, you can't "add" using these plug-ins. The SVG plug-in for example can't magically make Gimp understand vector images
No, but an SVG datatype can present itself as both bitmap and vector and an application that wants a bitmap can still read an SVG as if it were a bitmap.
> It's because there really were sixty different crappy pixmap formats that were completely interchangeable
Any data type that’s generic enough can present itself in multiple ways as long as it’s possible to translate (even if with losses) to those ways.
And indeed there's an SVG datatype, with an associated generic vector superclass on Aminet, updated last month, as well as a Cairo based SVG class that renders to bitmaps.
> Most applications gain nothing from having, say, yet another mediocre bitmap graphics format. You just made your system more complicated without any improvements whatsoever.
WebP is much newer than most Amiga applications. Since someone wrote a WebP datatype, an Amiga word processor written in 1994 can embed one in a document. An Amiga graphics app released in 1997 can open one and edit it. Literally every Amiga app that can use the datatypes API now supports it, without a single recompile or changed line of code, because someone wrote that loader. That’s pretty powerful.
That's literally just spelling. The exact same pictures could have been added to the document in 1994, only the file format changed.
People keep doing this, as others have observed. And they always get stuck in the same place, they can make different raster image formats work, although each time this happens they find there are fewer anybody cares about, and they can do the same trick with PCM audio, although again not many options anybody cares about (MP3 is about as exciting as you get these days) and then they run out of steam.
This is not a rich seam of unexplored possibilities, it's a small hole in the ground that people keep clambering down into - certain they'll find treasure and then disappointed when it is in fact just a small hole in the ground.
No, it's not "literally just spelling". It is additional manual steps vs. having the computer do things for us.
You keep arguing for inconveniencing users and developers, who still need the conversion tools anyway, to avoid standardising the conversion tools. It makes absolutely no sense.
Yes, it is. You don't even try to pretend otherwise, the format isn't delivering new semantics here. The existence of the extra formats that caused Datatypes to be created is an artefact of history, like TIFF, and best left there.
> It is additional manual steps vs. having the computer do things for us.
"Having the computer do it" for every format in every program incurs an unending maintenance and security burden for all systems across all time, whereas lift-and-shift averts that.
> You keep arguing for inconveniencing users and developers
You have chosen to inflict misery on yourself, I don't have any part in that.
> It makes absolutely no sense.
And yet I suppose that today you will continue as before, blaming others for things you choose, and perhaps lamenting that whichever bunch of crooks currently own "Amiga" aren't shovelling more money into the pit.
> Yes, it is. You don't even try to pretend otherwise, the format isn't delivering new semantics here. The existence of the extra formats that caused Datatypes to be created is an artefact of history, like TIFF, and best left there.
The formats exist and are being used, and new ones keep being created. That is the problem. You can keep pretending we don't need to deal with them. Maybe you don't, but I do have to deal with format conversion on a daily basis, as I don't live in a fantasy world where everyone chooses to use the formats I would prefer.
> "Having the computer do it" for every format in every program incurs an unending maintenance and security burden for all systems across all time, whereas lift-and-shift averts that.
Having the computer do it for every format in every program in terms of the actual conversion is exactly what we have today because of the lack of use of things like datatypes. On top of that we have piles of conversion tools to deal with moving data between programs that don't implement the same set of formats.
What we're lacking is automation and deduplication of effort.
There's no added security concern here to automating the execution of code we already execute.
If anything avoiding crappy reimplementation of formats all over the place would be a substantial reduction in complexity and make it easier to actually put in the effort to produce something more robust.
Meanwhile what you're engaged in is meaningless sophistry given that your proposed solution of just getting rid of these formats is not an option available to us.
> And yet I suppose that today you will continue as before, blaming others for things you choose, and perhaps lamenting that whichever bunch of crooks currently own "Amiga" aren't shovelling more money into the pit.
I don't care who currently own Amiga. It's entirely irrelevant to this conversation.
But your non-solution does not become any more of a solution whether or not I get the time to do something about my workflows.
> Most applications gain nothing from having, say, yet another mediocre bitmap graphics format.
Applications gain a tremendous amount of usability for me by being able to read or write the formats I actually use. Instead we rely on a hodgepodge of scripts and tools to do format conversion manually.
Amiga applications released decades ago can load webp files for example, whether or not the people who wrote them are still releasing updates or are even around. It might not matter to you. It matters to me that files keep being easily accessible.
Today there are plenty of tools I use regularly that can't load or save various formats I regularly use directly. That is pointless, when providing a mechanism to reuse conversion was a solved problem decades ago.
> Actually Gimp does. Gimp's file format handling is all via plug-ins.
But it's not reusing system-wide plugins, which was the point.
> You've almost understood. Instead of adding a layer of abstraction, and then unifying around this unnecessary layer, we instead chose to just use a specific standard format. The problem you're intent on solving vanished.
Unfortunately you failed to understand. We haven't unified on a standard format. We never will, because we get new requirements regularly, and people also create new formats for arbitrary and stupid reasons as well. Format conversion will always be necessary to handle formats produced by different tools.
We can choose to do that "out of band", or we can choose to re-implement it for applications time and time again, or we can move towards a unified system. Today we do the first two. A tremendous amount of time is wasted implementing conversion and loading and saving for different applications, and a tremendous amount of time is wasted on doing out-of-band conversion. I've spent the better part of the last month dealing with crappy data conversion because a tool I need to feed data into implements it's own conversion in a badly broken way instead of reusing a better one, forcing me to go via another format. The amount of developer effort wasted on this bullshit is massive, and the amount of inconvenience for users is too.
> Didn't you ever wonder why Datatypes seemed so brilliant for image files, and kinda sorta OK for music, and then basically of no value at all for most other file formats? It's because there really were sixty different crappy pixmap formats that were completely interchangeable and half a dozen PCM audio formats likewise. But that's not what happened in other domains, because it's pointless.
No, I didn't wonder that, because the limitation there was that Commodore went bankrupt and datatypes was not progressed to cover additional domains, and the Amiga community was not large enough to take on the task of covering more complex structured data options. Meanwhile we still depend on conversion filters for all kinds of other formats all the time for e.g. office suites. So no, it's not pointless.
It's not an interesting or useful difference. The thing Datatypes lets you do is pointlessly spell things differently. Once you spot that you ask yourself, "Why am I doing this?" and the answer is only that you need to interoperate with other people who hadn't settled on one way to spell things so the best route forward is consolidation.
Most applications gain nothing from having, say, yet another mediocre bitmap graphics format. You just made your system more complicated without any improvements whatsoever. Clearly we should agree to just stop doing this. And we did.
> Gimp doesn't
Actually Gimp does. Gimp's file format handling is all via plug-ins. As with ImageMagick in this context maybe you actually needed to rescue crappy 1980s files you found on a floppy disk or whatever. But this helps us see what's going on - because Gimp's image file format handling is only for import and export of necessity Gimp itself is richer than any of these formats. Its native XCF format reflects a superset of the features you can care about.
But anything Gimp's native images can't do, you can't "add" using these plug-ins. The SVG plug-in for example can't magically make Gimp understand vector images, it just has to render the vector image as pixels because that's all Gimp understands.
So in the end any innovation is rendered pointless by this abstraction, the only way for an innovative idea to flourish is to sidestep a "datatypes"-like abstraction altogether.
> actually unify around using a specific standard.
You've almost understood. Instead of adding a layer of abstraction, and then unifying around this unnecessary layer, we instead chose to just use a specific standard format. The problem you're intent on solving vanished.
Didn't you ever wonder why Datatypes seemed so brilliant for image files, and kinda sorta OK for music, and then basically of no value at all for most other file formats? It's because there really were sixty different crappy pixmap formats that were completely interchangeable and half a dozen PCM audio formats likewise. But that's not what happened in other domains, because it's pointless.