[c-lightning] plugin development

[Christian Decker]

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