12025-11-20T00:13:42  <stringintech> Ah you're talking about bindings depending on a json repo at a specific version and loading those files at runtime? in that case you're right, the overhead should be about the same. I was thinking about the dead simple alternative of hardcoding test data :)
 22025-11-20T00:28:45  *** stringintech <stringintech!~stringint@user/stringintech> has quit IRC (Quit: Client closed)
 32025-11-20T12:09:42  <stickies-v> oh yeah I was talking about the first, that seems like a low effort project with reasonable payoff
 42025-11-20T13:11:13  *** janb84 <janb84!~janb84@user/janb84> has joined #bitcoin-kernel
 52025-11-20T14:55:59  *** stringintech <stringintech!~stringint@user/stringintech> has joined #bitcoin-kernel
 62025-11-20T15:20:58  <janb84> so on the kernel-bindings-test :) My main problem was that the readme misses the actual run command of the runner. `./build/runner --handler <<custom handler>>. Needed to look into the go code for that xD
 72025-11-20T15:21:51  <janb84> Not sure about the naming in the method name but that a minor thing.
 82025-11-20T16:05:18  *** stringintech <stringintech!~stringint@user/stringintech> has quit IRC (Quit: Client closed)
 92025-11-20T16:05:45  *** stringintech <stringintech!~stringint@user/stringintech> has joined #bitcoin-kernel
102025-11-20T16:06:47  *** stringintech <stringintech!~stringint@user/stringintech> has quit IRC (Client Quit)
112025-11-20T16:07:06  *** stringintech <stringintech!~stringint@user/stringintech> has joined #bitcoin-kernel
122025-11-20T16:15:41  <stringintech> Sorry! :))) I'll fix that.
132025-11-20T16:16:10  <stringintech> On naming and terminology: I'd really appreciate your input on the json schema fields and/or architecture component names.
142025-11-20T16:16:22  <stringintech> About "method" specifically: on the handler component, we implement one handler function per "method". If we rename the handler component itself, we could potentially use "handler" instead of "method". Not sure if that's good enough though and I don't have an alternative for the handler component name yet.
152025-11-20T16:16:37  <stringintech> What do you think?
162025-11-20T16:31:14  *** stringintech <stringintech!~stringint@user/stringintech> has quit IRC (Quit: Client closed)
172025-11-20T17:01:43  *** stringintech <stringintech!~stringint@user/stringintech> has joined #bitcoin-kernel
182025-11-20T17:08:21  *** cfields <cfields!~cfields@user/cfields> has quit IRC (Read error: Connection reset by peer)
192025-11-20T17:57:16  *** stringintech <stringintech!~stringint@user/stringintech> has quit IRC (Quit: Client closed)
202025-11-20T20:04:08  <janb84> The project is nice, architecture is good (not a go native but my short assesment is that it is following the standards)
212025-11-20T20:08:28  <janb84> about the method naming, I was referring to the actual name of the method, not the json field. "script_pubkey.verify" the method in the kernel is called "btck_script_pubkey_verify". Maybe keep the kernel name ?