Solution to #67 and #68 : curl-based Provider configuration #69
Description
At the moment, our Provider configuration interface introduce a somewhat egregious layer of indirection over what is ultimately just a curl request constructor. Although each new design choice was sensible at the time, what we've ended up with is a bit of a mess that results in the kinds of issues discussed in #67 and #68 — I submit that we should radically simplify this into a text-selection based variable declaration flow, where the user submits a complete curl request, and then highlights text sections to indicate that they should be mutable (which is to say, exposed as parameters to the operator).
Here's some figmaslop of what I imagine this looks like:
The user makes a selection, hits the plus button, and gives the new variables a name, and that's it.
This eliminates the problem posed in #68 — if a certain set of variables are not meant to be mutable, just don't highlight them. It should eliminate the problem in #67 by dint of some more intelligent parsing: the Operator passes callArgs [["messages", "[{"role": "user", "content": "Please write a poem about songbirds"}]"]], and then the provider replaces the text defined in the "messages" variable in place. If the selected section was bookended by quotation marks, it'll be parsed as a string. If not, then it wont.
@Gohlub tell me what I'm missing here, this seems like it would work fine and make for a much cleaner flow, and potential Provider-runners can go straight from an easily obtainable "sample curl request" to "live provider" faster with no request type decision tree or anything like that. The one downside I can see is that this visual convention doesn't pattern match to how we would want to expose provider creation to LLMs themselves... but that doesn't feel like a big downside rn tbh.