Returning IntentResolution means an app needs to wait for a target app to finish handling an intent

[rikoe]

The latest changes include a ResolutionObject returned by raising an intent.

This is very problematic for the fire-and-forget use case. In our current implementation, the intent resolver will find a target application to pass the intent on to and do that, but it then returns to the intent originator without any guarantees about whether the target app could be started, successfully received the intent, and finished handling the payload.

I think mandating a ResolutionObject forces all intents to wait for the target app to finish handling the intent payload, thereby removing the ability to do fire-and-forget.

This is why I wanted to the fire-and-forget and request-response API to be separated. I am not sure they can be handled with the same API.

[nkolba]

The fact of ResolutionObject should not require the Desktop Agent to force an app raising an intent to wait until the target has completely handled the intent payload.

Also, the whole process is Async - so the App raising the event can handle the promise however it wants. The desktop agent would resolve the promise as soon as the intent is routed.

I agree that this probably isn't clear from the current Spec and TS definitions. I can clarify in the API documentation.

[rikoe]

I am not sure this works. How can the desktop agent "resolve the promise as soon as the intent is routed", but then also return a data object when the handling app produces it? You can resolve an intent successfully only once - when the intent is routed OR when the intent is handled.

The former means there is no opportunity to return a data object, the latter means the promise resolution will wait until after the intent listener returns a result (or completes if no result is returned).

I think they are mutually exclusive. The only way around this would be for the sending app to complete ignore the promise and just call "raiseIntent" and hope for the best, or to specify behaviour when raising the intent to say which of the two resolution options to use.

[nkolba]

The expectation here is that agents have an awareness of the intent raised - and can determine the timing of the resolve based on whether there is a data return or not. This should be part of the intent definition. By default, the agent would resolve upon routing of the intent.

…

Sent from my iPhone

On Sep 24, 2018, at 6:12 AM, Riko Eksteen ***@***.***> wrote: I am not sure this works. How can the desktop agent "resolve the promise as soon as the intent is routed", but then also return a data object when the handling app produces it? You can resolve an intent successfully only once - when the intent is routed OR when the intent is handled. The former means there is no opportunity to return a data object, the latter means the promise resolution will wait until after the intent listener returns a result (or completes if no result is returned). I think they are mutually exclusive. The only way around this would be for the sending app to complete ignore the promise and just call "raiseIntent" and hope for the best, or to specify behaviour when raising the intent to say which of the two resolution options to use. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[rikoe]

How can the agent know whether there will be data to return or not? We so far have not defined anything as part of the intent definition that indicates that. This feels like a big gap to me!

I am probably alone in this, but I will kind of feel better if we don't support this scenario in v1 of the spec and flesh it out and think it through better for the next version. (It is easy to extend an API that doesn't resolve data to one that does, but not the other way round.)

Even if we come up with a way to define it, we now have a raiseIntent function that resolves differently under different circumstances, that feels slightly dangerous to me...

[rikoe]

I think a good way to get around this would be the following: The intent always resolve successfully when dispatched, with only information about the application it was dispatched to.

Returning data (if required) should be done by a separate and optional callback. Then the API is always consistent in how it behaves.

[nkolba]

This makes sense to me. Perhaps the initial promise resolves with a data promise if there is a data return as well. So...

interface IntentResolution {
source: String;
data?: Promise;
version: String;
}

[rikoe]

What data will there be to return before the target application intent listener has been invoked? This risks being confusing I think, but I am open to persuasion! Shall we discuss this on the next WG call?

[rikoe]

This was discussed on the API working group call on 27 September 2018, and subsequent mailing list messages. Support will be added for intents to declare whether they return data or not, which will address this issue.