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 <x...@elsiehupp.com> 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 “ <with certain items removed>”). 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
