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