[c-lightning] plugin development

[Richard Bondi]

Thanks Christian,

This is exactly the approach I took, except with formatted json
response, but I updated to unformatted and the results I get are as
expected from the shell, so it seems my assumptions were correct.

However, I still have the issue as described.

I created a repository
https://github.com/rsbondi/clightning-dotnet-plugin/tree/9b0e73fa77691a40e3f2a010c8b8bff0deeb861a

This shows in the gifs that in shell I get the responses expected, but
when running clightning and calling commands from the cli, the result
is not as expected

> The JSON you posted got mangled somewhere, i.e., it's missing the
> quotes. I think this might actually be the shell doing random things
> with quotes. And testing with escaping or single-quoting the parameter
> seems to work:

My intention here was only to show that the plugin was registered and
responding to the command, but only on errors(mangled json), not on
valid input `lightning-cli hello fred`.
On Sat, Dec 8, 2018 at 2:38 AM Christian Decker
<decker.christian at gmail.com> wrote:
>
> Hi Richard,
>
> the plugins being simple executables that communicate over stdin and
> stdout should be able to be started directly from the shell and you
> should also be able to interact with the from there. So you can try
> starting your plugin and issuing some JSON-RPC requests and see how it
> reacts. For the initialization you should be able to do the following
> (taking the helloworld.py plugin as an example:
>
> ```
> {"jsonrpc":"2.0", "id":1, "method":"getmanifest", "params":[]}
> {"jsonrpc": "2.0", "result": {"options": [{"name": "greeting", "type": "string", "default": "World", "description": "What name should I call you?"}], "rpcmethods": [{"name": "hello", "description": "Returns a personalized greeting for {name}"}, {"name": "fail", "description": "Always returns a failure for testing"}]}, "id": 1}
> ```
>
> The first line is what you send, the second is the reply from the
> plugin. After that you can issue the `init` call:
>
> ```
> {"jsonrpc":"2.0", "id":2, "method":"init", "params": {"options": {"greeting": "Richard"}}}
> {"jsonrpc": "2.0", "result": "ok", "id": 2}
> ```
>
> And from hereon the plugin is registered and can start doing its
> magic.
>
> > When I call the plugin it just hangs.  I have tried just ignoring all
> > input and returning the same response as the init and getmanifest,
> > still hangs.  It seems the passthrough is taking place, if I put in a
> > command like
>
> This could have something to do with buffering, since some languages
> will buffer output. Notice that the python3 plugin always adds newlines
> and flushes to make sure it clears buffers. Not sure how the situation
> is with C#, but python2 was acting up as well.
>
> > cli/lightning-cli hello {"greeting":"fred"}
> >
> > I get a response
> >
> > Invalid token in json input: '{ "method" : "hello", "id" :
> > "lightning-cli-25109", "params" : [ {greeting:fred}] }'
> >
> > which make sense, if I do an echo passing the same json I get the
> > broken json
>
>
> The JSON you posted got mangled somewhere, i.e., it's missing the
> quotes. I think this might actually be the shell doing random things
> with quotes. And testing with escaping or single-quoting the parameter
> seems to work:
>
> ```
> lightning-cli hello '{"greeting":"fred"}'
> "Hello {'greeting': 'fred'}"
> ```
>
> > what I expect to happen is, when I type in
> >
> > cli/lightning-cli hello fred
> >
> > I expect my message with "fred" substituted in or I expect the command
> > that I look for in code to be
> >
> > { "method" : "hello", "id" : "lightning-cli-25109", "params" : ["fred"] }
>
> The reason you get the full quoted text back is because `lightning-cli`
> takes that first argument (the JSON serialized object) and passes it in
> as the first positional parameter, and doesn't use the entire object as
> the params (i.e., it doesn't unpack). So to get `Hello fred` you'd have
> to run `lightning-cli hello fred` instead.
>
> > The other issue is when I try to do in go, it seems to call
> > `plugin_read_json_one` more than once for the same plugin's
> > getmanifest and I get the "Received a JSON-RPC response for
> > non-existent request" error.  It seems to have the same buffer value,
> > but no request.  I have gone as far in my code to remove getmanifest
> > from the map so there is no way it could erroneously send the request
> > a second time.
>
> This could happen in a couple of different ways: the plugin code issues
> the request twice (this would be a lightningd bug), the plugin responds
> multiple times (bug in the plugin), the plugin code doesn't clear the
> buffer inbetween responses (lightningd issue).
>
> We can easily eliminate the second case by running the plugin from the
> command line like explained above, and go from there.
>
> HTH,
> Christian