Provide guidance to UAs on appropriate names for "platform" members

[mgiuca]

Currently, the advice on what UAs should name their platform member is fairly vague:

A platform represents a software distribution ecosystem or possibly an operating system.

This has caused some recent confusion as getInstalledRelatedApps is being incubated, which uses the platform member of the related_applications member to determine whether to look at a particular app.

In particular, there is confusion as to whether to name the platform after the application store (e.g., "play") or the operating system (e.g., "android"). Historically, Chrome has used "play", but that was for promoting installation of a native application from the Play Store; now it seems "play" is being used by getInstalledRelatedApps to check for any Android APK, and it seems using the OS name would be more appropriate there. (Or, as @dominickng says on that thread, filter to only report apps installed by the Play Store.)

We could possibly offer more guidance around when to use the name of the store, and when to use the name of the OS. It's possible that both are appropriate, depending on the context.

Some possible text:

A platform represents a software distribution ecosystem or operating system. The user agent SHOULD ignore objects whose platform is not recognized. A user agent may recognize platform values named after both software distribution ecosystems and the host operating system. If a platform value is named after a software distribution ecosystem (e.g., "play"), then it SHOULD only be used in contexts specific to that ecosystem. On the other hand, if a platform value is named after an operating system (e.g., "android"), then it SHOULD be used in all contexts within that host operating system.

This also means that the example under purpose member is (retroactively) wrong: it uses "play" when talking about icons "specifically designed for the Android platform", when it should use "android", since presumably that icon should also be seen when installed from another store. In general, it doesn't make sense for ImageResources to have a store platform; they should always have OS platforms.

[aarongustafson]

Your suggestion makes total sense to me. The platform member isn't defined in just one spot though, right?

[mgiuca]

It is defined centrally and linked from both ImageResource and ExternalApplicationResource (which could represent a problem for splitting out ImageResource). See https://www.w3.org/TR/appmanifest/#platform-member-0

[aarongustafson]

It is defined centrally and linked from both ImageResource and ExternalApplicationResource (which could represent a problem for splitting out ImageResource). See https://www.w3.org/TR/appmanifest/#platform-member-0

Thanks for clarifying. We were not including platform as a member of ImageResource, so it would just exist in the subclass within the manifest spec, so I think we’re good.

[kenchris]

Not used beyond related_applications in Blink:

https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/public/common/manifest/manifest.h;l=28?q=ImageResource&ss=chromium%2Fchromium%2Fsrc:third_party%2Fblink%2Fpublic%2F&originalUrl=https:%2F%2Fcs.chromium.org%2F

Not used in Firefox according to @marcoscaceres

Not used in WebKit:

https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/Modules/applicationmanifest/ApplicationManifestParser.cpp

[aarongustafson]

In supporting screenshots in the App Info spec, I have established a Wiki page documenting platform values. Perhaps we can reference that?

On a somewhat related note: Does anyone think it might make sense to move related_applications to the App Info spec?

[mgiuca]

On a somewhat related note: Does anyone think it might make sense to move related_applications to the App Info spec?

related_applications is directly used by the in-incubation getInstalledRelatedApps feature, which is implemented in browsers, not by other processors. Now, that's in incubation, but my point is that it's difficult for both new APIs to be designed or for browser manufacturers to make use of metadata if it's "not really part of the manifest, just supplemental information".

Honestly, I wish we didn't split the manifest into App Info vs main. As I argued when it was proposed, I think it's an unhelpful distinction to say "these members are for browsers" vs "these members are for other manifest processors". What if a browser wants to use a member from App Info, for example if we wanted to start displaying screenshots in the browser at install time?

[aarongustafson]

I agree. I sincerely hope that we can incubate App Info and then merge it back.

[christianliebel]

Now that we have App Info, does it make sense to move related_applications there?

Currently, we have duplicate definitions of known platform values:

1. One for related applications (https://www.w3.org/TR/appmanifest/#platform-member) here in our Wiki (https://github.com/w3c/manifest/wiki/Platforms)
2. And App Info defines platform values for screenshots (https://www.w3.org/TR/manifest-app-info/#platform-member).

(Speaking of the wiki, we could also retire the Categories page, and maybe the TPAC 2018 page as well.)

[mgiuca]

@christianliebel Aaron asked the same question above; see my response.