Re: Feature request to expand MIME in order to allow application register default treatment of directories with custom extension
Some clarification via the documentation and also this StackExchange answer from 2008: https://stackoverflow.com/questions/121147 macOS `DocumentPackages` do not need an internal `Info.plist`; rather, filetypes are registered with the operating system via the `Info.plist` of an application that supports given filetypes. It seems like once a `DocumentPackage` extension is registered with the operating system, Spotlight will automatically set the Uniform Type Indicator “com.apple.bundle” and/or “com.apple.package” under `kMDItemContentTypeTree`. For example, if you append `.rtfd` to an arbitrary directory, then run `mdls` against it, among other output you should see: > kMDItemContentType = "com.apple.rtfd" > kMDItemContentTypeTree = ( > "com.apple.rtfd", > "com.apple.package", > "public.directory", > "public.item", > "public.composite-content", > "public.content" > ) It’s been a while since I’ve run into the issue, but if I remember correctly it’s possible to have a directory with a known package extension and have the operating system not recognize the directory as a package if you bring the directory over from another filesystem. I believe the above information is stored as an extended attribute under `com.apple.metadata:kMDItemContentType` and `com.apple.metadata:kMDItemContentType`, but I’m not 100% sure. Obviously an extension to the MIME standard shouldn’t use Apple’s internal extended attributes. At the same time, some degree of cross-compatibility on the Linux end would be nice, and an extension to the MIME standard would be more likely to be supported on the macOS and iOS end (i.e. at a bare minimum not mangling any packages following such a standard). Anyway, the way that macOS applications register package types seems very closely analogous to the way `.desktop` files register MIME types. That said, it could be nice if packages could “self-register” using internal `.desktop` files, albeit obviously without the the `Exec` key.
Re: Feature request to expand MIME in order to allow application register default treatment of directories with custom extension
My initial email from yesterday got held back because the size was too big. Hopefully this version makes it through. Begin forwarded message: From: Elsie Hupp Subject: Re: Feature request to expand MIME in order to allow application register default treatment of directories with custom extension Date: June 17, 2022 at 3:00:12 PM EDT To: xdg@lists.freedesktop.org Hi H.G., et al, One potentially useful precedent here is RFC 2557, or “MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)”: https://datatracker.ietf.org/doc/html/rfc2557 <https://datatracker.ietf.org/doc/html/rfc2557> I’m not entirely sure why this never caught on. … Another potentially useful precedent is the AppImage Project (discussed further in the conclusion): https://appimage.org/ <https://appimage.org/> … The related format for macOS is called `CFBundles`, specifically the `CFBundles` subtype `DocumentPackages`: https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/DocumentPackages/DocumentPackages.html <https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/DocumentPackages/DocumentPackages.html> CFBundles are structured something like the following: Note that this example has most of the contents removed, and I manually changed the icon of the topmost folder, because you can’t actually show the contents of a CFBundle in this way in the Finder unless you break the extension (i.e by literally adding the string “ ”). On an aggressively simplified level, the contents are as follows: (1) `Info.plist` is an XML manifest describing the contents so that the operating system knows how to treat the bundle. (2) The `MacOS` directory contains any executables. (3) The `Resources` contains almost everything else, such as, for example, the application icon, etc. `CFBundles` that are not applications only need a top-level `Info.plist` (with or without the `Contents` directory) and can use basically any directory structure they want, but historically `DocumentPackages` have used structures very similar to application bundles. Also IIRC at some point Apple added the ability to have `CFBundles` that are ZIP archives, but I don’t entirely know what’s involved with that. It’s worth mentioning that Apple has moved away from `DocumentPackages` (as evidenced by the fact that the documentation for them is no longer updated) as they have instead encouraged developers to use obfuscated storage in the `~/Library` folder, since this type of storage works better when cloud-syncing user data with iOS apps. … While it would be nice if Linux file managers had at least a basic level of support for `CFBundles` (i.e. showing them as “files" rather than as “folders”, along with some clever icon heuristic, even if only to keep users from accidentally mangling them), and it would be nice if bundles created by Linux applications also “just worked” on macOS, there isn’t any inherent reason an XDG standard would need to be 100% cross-compatible with the corresponding macOS format. That said, the basic idea of `CFBundles`, with a “file extension” appended to a directory and an XML (or similar) manifest explaining (though not necessarily enumerating) the bundle’s contents could be a good place to start for a similar XDG standard. Considering what standards XDG does already support, some starting points for a manifest format could be: The XDG Desktop Entry specification: https://specifications.freedesktop.org/desktop-entry-spec/ <https://specifications.freedesktop.org/desktop-entry-spec/> The XDG AppStream specification: https://www.freedesktop.org/software/appstream/docs/ <https://www.freedesktop.org/software/appstream/docs/> (The Desktop Entry specification is probably more applicable, though.) The AppImage Project may also be relevant to an extent (as it parallels the portability of macOS application bundles): https://appimage.org/ <https://appimage.org/> One potential option for cross-compatibility could be a mostly boilerplate `Info.plist` “wrapping” an XDG Desktop Entry (rather similar to or even compatible with the AppImage `AppDir`), though I know little enough about how either format is parsed to know how exactly this sort of hybrid bundle would be implemented. … Anybody else have any thoughts here? Best, Elsie Hupp
Re: Feature request to expand MIME in order to allow application register default treatment of directories with custom extension
Am Fr., 17. Juni 2022 um 08:16 Uhr schrieb 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
Re: Feature request to expand MIME in order to allow application register default treatment of directories with custom extension
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 t