498 Allow intents to be resolved on output type (where they return data) #499
Conversation
…ndIntent API calls
kriswest
requested review from
rikoe,
mattjamieson,
donbasuno,
ggeorgievx,
a team and
thorsent
| ```typescript | ||
| enum DataError { | ||
| NoDataReturned = 'NoDataReturned', | ||
| IntentHandlerRejected = 'IntentHandlerRejected', |
There was a problem hiding this comment.
We may need some more discussion around error handling. For instance, a request for a quote would likely return some sort of well-defined "Quote" context, but what if the end user is not authorized to receive that market data? We wouldn't want to muddy the Quote context with arbitrary error messages, but then the DataError enum type provides no information about why the intent was rejected, which in this case would result in quite a bit of potential confusion for the end user.
We may want to either (a) consider allowing at least a simple error string to be rejected/thrown, or (b) allow for the possibility of more than one context being returned (e.g. an Error context. Receiving apps may then disambiguate by examining the type member).
There was a problem hiding this comment.
At present, an app resolving an intent has no means to identify the app raising the intent and couldn't assess authorization. Hence, any such mechanism would have to be a function of the Desktop Agent. However, I take the point on returning some info about why the promise was rejected (for feedback to the end-user - 'IntentHandlerRejected' is not all that informative and we are deliberately losing any info on why the rejection occurred).
I don't particularly like the idea of using an 'ErrorContext' type (I think that overloads the purpose of context). However, we could use the javascript Error type (or similar that we define), setting the message to these values and setting the optional cause property to the error/rejection message returned by the intent handler... However, its a departure from all other rejects, which reject with just a string.
src/api/DesktopAgent.ts
Outdated
| * | ||
| * Using `raiseIntentForContext` is similar to calling `findIntentsByContext`, and then raising an intent against one of the returned apps, except in this case the desktop agent has the opportunity to provide the user with a richer selection interface where they can choose both the intent and target app. | ||
| * | ||
| * Returns an `IntentResolution` object with a handle to the app that responded to the selected intent. | ||
| * Returns an `IntentResolution` object with details of the app that was selected to respond to the intent. If the application that resolves the intent returns a promise of Context data, this may be retrieved via the `getResult()` function of the IntentResolution object. If an error is thrown by the handler function, the promise returned is rejected, or no promise is returned then the Desktop Agent MUST reject the promise returned by the `getResult()` function of the `IntentResolution` with a string from the `DataError` enumeration. |
kriswest
added
channels feeds & transactions
kriswest
changed the title
Co-authored-by: Terry Thorsen <terry@chartiq.com>
kriswest
force-pushed
the
498-resolve-intents-on-output-type
branch
from
929b287 to
b88b4af
Compare
|
Closing in favour of #508 which contains all the same commits |
Adds an element to the AppD Application schema that can specify the Context type that intent can return and extends the
findIntentAPI calls to be able to use it for resolution.Support for this was not added to the
raiseIntentAPIs as:findIntent)