We need a **clear** way for providers to communicate their needs to consumers

As of now there is no great way for a provider to indicate "Hey I need X" to the calling consumer. This is by design, a provider should never directly interact with the user, and consumers should never directly interact with providers.

However, there are absolutely cases where a provider may need some form of input from the end user. As they are not allowed to talk to the end user directly and the end user cannot talk to them, we have put the provider in the impossible position of "figuring" out how to do something where it needs input from the user. An example, your provider needs a password (for something. Lets say SSH). The provider simply cannot do its job in that situation.

There are a few different ways I have played with for this but none are "great".

My current thought process is that the provider returns something in their response (similar to how the error attribute works in responses) that says "Hey I need X. Get it for me with this prompt string and then call this callback with whatever you get so I can continue processing". The obvious issue with relying on callbacks however is that forces consumers (and providers) to operate asynchronously by default. Which is fine but per #117 we just don't have an asynchronous framework in place yet (and it wont be the default interaction mechanism for the API). This isn't bad per say, but it does add alot more complexity to what should be an otherwise simple process.

Currently, (synchronously) opening a resource looks like this

execute api.read on resource
check to see if there were any errors in read. If so, display them and quit
evaluate the type returned (file, explore, stream)
otherwise, display/open the info for the end user to interact with

Adding something like above turns this into a more complex set of steps

execute api.read on resource
check if there are any errors in read. If so, display them and quit
evaluate return info to see if the call is being processed asynchronously
- if so, save the returned handle and check on it later (somehow)
otherwise, check to see if the provider wants something
- if so, request whatever from the end user and call the provider's callback
- wait for the callback to finish (or provide a callback of our own?) so that we can finish read
If synchronous (or the async is complete), display/open the info for the end user to interact with

It is very important that we maintain the provider cannot directly get this information as the rendering UI may be anything from vim itself to a GUI program over top, Neo-tree, or who knows what. Netman (nor the provider) can ensure UI likeness in its prompts with whatever consumer reached into it. So instead we should rely on bubbling.

Tagging @chipsenkbeil for thoughts (or ignore this, thats absolutely fine too 😄) as this is directly related to a bit of conversation we had on #150 (adding some sort of "connection" mechanic to the provider spec).

miversen33 / netman.nvim

We need a clear way for providers to communicate their needs to consumers #151

miversen33 / netman.nvim

We need a **clear** way for providers to communicate their needs to consumers #151

We need a clear way for providers to communicate their needs to consumers #151