Feature request to expand MIME in order to allow application register default treatment of directories with custom extension

[notebook]

To Whom it may concern / Dear XDG Team,

I'd like to add a use case I consider important:

You would finally be able to version complex file types like odt or odf (e.g. in git), which are currently unversionable, because they're zipping themselves.

Regards
Chris / DarkTrick


On 2022/06/17 21:15, Hossein wrote:
> —
> 
> To Whom it may concern / Dear XDG Team,
> 
> I'm writing to you regarding "MIME" specification.
> 
> If I'm not wrong, I was born after the internet has become accessible to the average users in the United States, so I understand that I might not have the same association with certain ideas and concepts; and that is particularly where I think one of the roots of my proposal is.
> 
> Short: I have been drafting a few desktop applications here and there, and one of the problems I have faced is storing data in a manner that can be easily understood by the end-user; i.e. from the perspective of the end-user, the difference between a file or a folder, or a symlink isn't that obvious. What is obvious is that for example: this file is going to be opened with this application and it is going to have this content.
> 
> and I understand that back in time, defining your own custom file format was the way to go; and since web applications became widespread storing everything on the Cloud became super widespread; However, it appears to me that we missed a real need for applications that are too complex to grant developing a custom file format from the ground up.
> 
> Let me give you an example which you might be familiar with.  I'm currently using VS Code but you can replace that with your favorite editor. Most developers usually stick with a single editor for a single project; and usually the main bulk of the project is within a certain directory; However, that directory itself can be moved from one place to another. VS Code works around this idea that directories can be aimed at being opened by VS Code vs by any other application, i.e. it might be a music directory not a code directory, by allowing you to define a ".Workspace" config file.
> 
> and that solution works perfectly fine if you don't move around the root directories or you work on a few projects, but if you're shuffling 10 or 20 projects around and trying to open them on VS Code, you will have a horrible time of doing it via ".Workspace" solution.
> 
> So, instead of calling it a "solution", let's call it a "work-around".
> 
> Let me give you another example: especially for individuals who do research on contents delivered via the web, being able to save the original web-page is quite a substantial task. The problem is that nobody has any idea how to do it, just right. For example, you have Firefox going with the idea that "hey, let's create a folder with the same name as the webpage but instead of ending in '.html' it will end in '_files'!" While that may sound ideal from Firefox's developer perspective, imagine you have 100 such files and folders in a directory and you want to move one around after you have renamed it. Ops, it looks like you forgot to rename the associated folder, and now you're lost in a bag of folders trying to figure out what was the name you save the article originally!
> 
> This is madness. These "solutions", are in my experience, super imperfect "workarounds"!
> 
> Again, there is no exaggeration going on here, imagine you're writing a text on how a news organization changed their report within 24 hours a couple of times; If you save the same web page let's say 10 times, you will have 20 files and folders with names that are super similar. and since you're not a robot, you prefer to rename them with the most significant change that was made, instead of a number. You'll easily mess up everything during one of those file changes! because you're working on ten other things at the same time while keeping track of the changes that other publication is making.
> 
> So, what would be a solution?
> 
> For example, if the Firefox save functionality stored everything in a directory with a ".fhtml" extension that meant: there is an "index.html" that has the same function as the aforementioned .html file and "files" directory that had the same function as the aforementioned "web-page_files" directory.
> 
> or in the case of VS Code, imagine that once you added ".vc-code" extension to a folder, simply double-clicking on it, would open it in a VS Code application. Now, regardless of how many times you're shuffling it around, you don't need to reconfigure a "workspace" file and save it somewhere and maintain that structure.
> 
> These are the existing issues; The actual reason why I'm asking for what I'm asking for, is for a totally different reason:
> 
> Developing applications that are built on top of existing file formats, i.e. they are not meant to re-invent the wheel, and additionally, they don't trick the user into storing their data in our servers, so we can sell their information and make money.
> 
> Obviously, the old fashion way of doing this would be to force the user to keep everything in the same place, and never move them around, in fact, the operating system environment has become really apt in doing it; You have "Music", "Pictures" and other folders there by default.
> 
> Imagine that you could add a ".album" extension to a folder and that folder would be treated as a music album. or at least something like ".music-album" and ".music-playlist" so that different applications just work with the same folder by default. No need to transfer config files and etc.
> 
> and these are very basic functionalities; imagine you are creating an application that mixes images, texts and etc. You don't necessarily want to reinvent a new file type, and in fact, you may not want to store everything in a .sqlite file. How about the application having ".sqlite" and a folder dedicated to all the photos and all that packed within a singular directory as ".my-application". So that when the user is moving things around, nothing gets lost; Or when the user decides to rename the main directory, there is no need to rename tons of other things, or save the changes in a config file.
> 
> Basically, the feature I'm asking for is the ability to be able to define custom "file extensions" for "directories". i.e. "inode/directory" when ending in an extension and that extension registered by a MIME type, it is going to be opened by a registered default application.
> 
> I believe, this is very essential. and I believe, this is not a revolutionary idea; I'm not that familiar with how Mac OS does things under the hood, but I believe they do some juggling like this.
> 
> I understand that for an old-school programmer, treating files and directories as essentially the same thing is akin to blasphemy but I think the below procedures are really ridiculous [for today's use-cases]:
> 
> - to define a custom file type for every single application. That only encourages tricking users into either selling their data to the cloud services, or encourages the developer to lock-in the user. For example, in case an application that uses existing file formats and goes bankrupt or discontinues, an open source developer can simply open that directory, take a look at the files and write their own application. They don't need to write an interpreter for that custom file format; Encoding and decoding binaries.
> 
> - to define config files that are only useful as long as you keep everything in the same place and never move from the application that can process that config file.
> 
> - to define folders with a certain symbol to coerce the user to store their files there so multiple applications actually know where a certain file is; i.e. Picture, Music, etc folders. If you have a directory with a music album deep in your file system, you should be able to click it and have it be opened and recognized as an "album" by the default music player. Yes, music players have become smart and can open files after one another as if it is an album, but again, "work around" and not a solution.
> 
> While I totally agree that nothing comes close to the performance gains by defining a customary file format, at the same time, an SQLite database associated with a series of .MD files is a much better solution to a notebook than having your notes stored in a cloud. With modern computers the performance penalty is not even there [definitively not compared to waiting for an internet connection to reflect the changes you have made and having your data lost if there was a connection lost & the app isn't well written to handle such niche cases]! and using pre-existing file formats, with the addition of a SQLite to give more context to the files, is a much better and much more longevity encouraging solution that custom file formats. Which is what MIME types are actually encouraging. as far as I could figure out.
> 
> Again, SQLite itself advertises itself as an "application file format" [read: https://www.sqlite.org/appfileformat.html], which though I totally agree with, I think, for an actual modern-day application, you're probably going to store images, or videos, audio, or ... SQLite can be viewed as the core organizational skeleton for the application file format, but it certainly doesn't satisfy 99% of use-cases on its own.
> 
> Because in the specification there was nothing about "inode/directory" being expanded to include complex application formats.
> 
> So, to wrap it all up, the feature I'm asking for:
> 
> *The desktop environment should enable effective communication between the OS, the end-user, and the preferred application by the end-user to process a collection of files that embody a distinct identity. i.e. a web page with all the bells and whistle [js, css, pictures, videos, etc] as a singular identity instead of a "directory" next to a "file". From my understanding, the cleanest approach is to allow applications to register "custom extensions" for what is from the perspective of the OS a directory. *
> 
> This approach encourages reusability of existing file formats and encoding and decoding paradigms, discourages developers from locking in the user, or selling their data to third-parties by circumventing storage on local devices and opting for the cloud, and allows user to focus on what they really want to do with a complex set of files and folders, instead of having them act as robots maintaining the integrity of that files and folder structure in order for it to be recognized as by a particular application, or otherwise maintaining an updated config file per application "workspace".
> 
> Regards
> 
> H.G.
> 
> PS. Thanks for keeping an open mind!