define AAP conformance profiles?

[atsushieno]

I figured that there are people who expect that an implementation of some advanced plugin format should provide all the advanced features the format provides, or it should not exist (there were such people in CLAP community), otherwise a plugin should stick to other (old and boring) formats.

While I don't agree with such an idea in general, It might make sense to some people. At least they have expectation like "If this host supports plugin format X, then it should support the feature A that X provides." kind of, and it is not too unfair (it basically is though, unless it is the required basic feature).

We explicitly declare "inclusive standard". Host developers should feel free to provide incomplete implementations, so as plugin developers. To defend those developers from unnecessary claims from the other party mentioned above, it probably makes sense to establish "AAP conformance profiles" that could reduce extraneous expectations.

Here are some ideas:

• Minimum plugin profile
  • implements what android-audio-plugin.h defines.
• Core plugin profile: Minimum plugin profile plus...
  • more than one instances can be instantiated.
  • implements the following extensions: plugin-info, parameters, midi and state
• Minimum host profile
  • can load a "Minimum profile" plugin
• Core host profile:
  • can load more than one "Core profile" plugins
  • can load plugins from more than one plugin services

We can additionally introduce new version profiles e.g. "AAP Version 1.2 Core profile" (that newly includes x, y, and z...).

Take it like SVG Tiny, Basic, and full profiles.