Am Fr., 17. Juni 2022 um 08:16 Uhr schrieb Hossein <hoss...@vitualizergalaxy.xyz>: > > — > > 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!
This sounds a lot like the concept of 'bundles' that you'll find on NeXTSTEP and its descendants, most notably macOS. One of the important things to their functioning is a standard file that describes that 1) it is a bundle, 2) what kind of bundle is it, and 3) other metadata that is wished to be used. On macOS, this takes the form of the Info.plist file, an XML file containing the above information. Having the only indicator of a type of a file (or in this case, a folder) be solely limited to its suffix is kinda silly and will probably result in a ton of fragility, where a user has a folder hierarchy meant for apps, but they don't know which app to use to open it, since unlike a single file, there's no one place to look for information to infer its type, but rather, a whole bunch of places. In short: this idea needs a standard file to include metadata, most importantly, the bundle's type, otherwise it'll probably end up being too fragile knowing what kind of bundle it is.
