Overhaul availability testing and add expected language options #22
+436
−285
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
DO NOT MERGE YET AS THE SPEC IS NOT FULLY UPDATED, JUST THE EXPLAINER
Add options for
expectedInputLanguages
,expectedContextLanguages
, andoutputLanguage
. The former two are used for downloading additional material and early errors if the web developer's required input/context languages cannot be supported by the browser. The latter gives clarity about what to do given mixed-language inputs.Remove the
capabilities()
method and the accompanyingAI*Capabilities
classes. The reasoning is as follows:Those classes had three APIs:
available
,createOptionsAvailable()
, andlanguageAvailable()
.languageAvailable()
wasn't clear if it was talking about input, context, or output languages. Now that we have explicit options for those three, we could fold language availability testing intocreateOptionsAvailable()
. But then, we can note that theavailable
property is kind of useless, as just knowing that some possible combination of options/languages is supported is not helpful for any known use case. So, the only real functionality we care about is testing whether a given set of options tocreate()
is supported.This was previously done via
(await ai.apiName.capabilities()).createOptionsAvailable()
. We instead expose it viaawait ai.apiName.availability()
. This name is a bit clearer, and this design also avoids the complexity where we have to retrieve all the availability information for every combination of options during the call tocapabilities()
, for later sync access. Now we can just retrieve the relevant information during the call toavailability()
.This was previously discussed in webmachinelearning/prompt-api#29; see especially webmachinelearning/prompt-api#29 (comment). Closes #16.
See also webmachinelearning/prompt-api#69 and webmachinelearning/translation-api#31.
Preview | Diff