Re: Feature request to expand MIME in order to allow application register default treatment of directories with custom extension

[Elsie Hupp]

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

[Elsie Hupp]

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 


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/ 

…

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
 


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/ 


The XDG AppStream specification:
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/ 

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

[J Blackquill]

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, 

Re: Feature request to expand MIME in order to allow application register default treatment of directories with custom extension

[notebook]

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 

Feature request to expand MIME in order to allow application register default treatment of directories with custom extension

[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 
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