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

[Hossein]

—

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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20220617/e9fe134f/attachment.htm>