Reason for supporting different image formats

[lawl]

From design goals:

• Support different image formats (squashfs remaining the default for now)

I don't quite understand what advantages this brings. From my POV this only seems to introduce unnecessary maintenance overhead. I might be missing something here but:

• Either the AppImage ships a runtime that can load it's payload and you don't have to care about it
• Or you want to have different tools accessing the payload in which case you'd probably want to mandate exactly one format to keep things simple and compatible.

[lawl]

Potentially similarly:

• Provide alternative implementations made in different languages

Not sure I understand this either: What benefit is there to maintaining multiple official implementations? The payload shouldn't care what language the stub is written in. Either it works fine, or it doesn't and someone (hopefully) makes a better one.

[TheAssassin]

Retrospectively, I don't recall any payload formats other than squashfs which I'd like to see supported officially. I guess one of the reasons is that there already are some (only partially compatible) implementations that don't use squashfs but claim to be AppImages. Almost all tooling around type 2 makes the assumption that the payload is squashfs, but it isn't really mandated by the specification.

I think I could live with enforcing squashfs at this point. But as you noticed in #8, there is some interest in alternative payload formats as well. Heck, we could even support mixing different payload formats and (fake-)overlay-mounting them.

Edit: by the way, I'm pretty sure a type 3 should specify a way to extract desktop integration data without having to read the payload format as a fallback.

What benefit is there to maintaining multiple official implementations?

This doesn't discuss the possibility of having different "official" implementations (although there certainly could be more than one, e.g., a C and a Rust one), but also really allow third-party-written runtimes. The point in standardizing is to allow such development, not to prevent it. As said, there already are some alternative (experimental?) runtimes for type 2.

What could set off official runtimes from third-party ones is code signing. We could provide properly signed releases.

[lawl]

Heck, we could even support mixing different payload formats and (fake-)overlay-mounting them.

Absolutely you could, and yes, you could make a ELF+PKZIP polyglot or more. the reason I asked these questions is that with any feature there's a complexity/benefit tradeoff. So I don't think any of these things should be done :)

This doesn't discuss the possibility of having different "official" implementations

I see, having a decent spec so that someone could make a third-party runtime seems sensible.

As for the code signing (and we're going off topic again here i suppose). If the user downloads and runs an appimage, they run the payload anyways (you have already written about sandboxing in #10). So I'm not sure if having a signed runtime brings any tangible benefit over just signing the entire AppImage with software vendors keys, as you'll have to trust them anyways.