Greg Wilkins

@lorban > a lot of places where an `Invocable` is passed to `demand()`, the `InvocationType` is pre-computed at the time `demand()` is called, not when the demand callback is to...

@sbordet > I really would not go into trying to put another smartness to fix this, but rather just document clearly the API or deprecate it. "This fix" is not...

> The above is my main motivation to say we should deprecate all our `CompletableFuture` API. I think we should fix all our CF usages (it is not proving to...

For our CF based utility classes, we have two distinct styles of usage: 1) in our adaption to blocking APIs (e.g. in ServletApiRequest) we often do: ```java Fields formFields =...

The CF fix works but is counter intuitive, fragile and mind blowing when combining CFs as we do going from core Parts to servlet Parts. So I've pushed some changes...

@sbordet I think we are agreed that ultimately we want to remove CF for our implementation and API. However, currently it is in our API (although deprecated by this PR),...

@lorban thoughts on the API comment above?

@sbordet @lorban I've converrted the FormFields class to use `Promise` on the new API and it works fine. Can you review that as a priority and if OK I'll convert...

@sbordet @lorban I'm liking the new `getXxx()` and `onXxx(Promise)` APIs. So my mind is turning more towards the implementation. Currently we are still using a `CF` internally, as it is...

> @gregw the `SerializedInvoker` issue we discussed is as follows: @sbordet So do you think we should write a simplified SerializedInvoker that only prevents infinite recursion but does not support...