3 ms·

I hear you, but they would still say fuck it. They will not think of a proper mime type. What would it be? application/x-studio-game-texture-format-3 If one doe

by hawski 6y ago

I hear you, but they would still say fuck it. They will not think of a proper mime type. What would it be? application/x-studio-game-texture-format-3 If one does not care enough with file extensions they will certainly not care with a mime type.

scrollaway 6y ago
That's not really the point. They likely wouldn't have a content type. File extensions on linux are treated as more of a hint. The point is that if content types were actually stored separately, it would be possible to not rely on detection. Furthermore, it would also be possible to know about a file's content type without it being present on the user's system. You see, in xdg, there is a core database of content types and how to detect them, and more can be installed with programs if they care to do that. But if a file's content type is not in that db, it's unknown to your system entirely. So your system doesn't know that it doesn't know. It's very inconvenient.
- lmm 6y ago
  Why would adding a new custom mimetype and marking those files as using it be any easier than adding a new custom file extension and renaming those files to use it?
  - scrollaway 6y ago
    I don't think we're talking at the same level. Implementing content types at the file attribute level simply allows more flexibility in terms of handling file types. I might write a proper blog post about this if I get some time to get my thoughts together. I worked for a year or so on this and with the xdg spec, it's all implemented in pretty frustrating ways.
- shawnz 6y ago
  At best the mime type in the file attributes would also be a hint (since there are many situations where it could be lost or not specified at all). So, what makes it a better hint than file extensions? If you see an extension you don't recognize, why is that any worse of a signal than a mime type you don't recognize?

by hawski 6y ago

scrollaway 6y ago

That's not really the point. They likely wouldn't have a content type. File extensions on linux are treated as more of a hint. The point is that if content types were actually stored separately, it would be possible to not rely on detection. Furthermore, it would also be possible to know about a file's content type without it being present on the user's system. You see, in xdg, there is a core database of content types and how to detect them, and more can be installed with programs if they care to do that. But if a file's content type is not in that db, it's unknown to your system entirely. So your system doesn't know that it doesn't know. It's very inconvenient.

lmm 6y ago
Why would adding a new custom mimetype and marking those files as using it be any easier than adding a new custom file extension and renaming those files to use it?
- scrollaway 6y ago
  I don't think we're talking at the same level. Implementing content types at the file attribute level simply allows more flexibility in terms of handling file types. I might write a proper blog post about this if I get some time to get my thoughts together. I worked for a year or so on this and with the xdg spec, it's all implemented in pretty frustrating ways.
shawnz 6y ago
At best the mime type in the file attributes would also be a hint (since there are many situations where it could be lost or not specified at all). So, what makes it a better hint than file extensions? If you see an extension you don't recognize, why is that any worse of a signal than a mime type you don't recognize?