—
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!
