Exact match with Bitcoin core API(?).

[jaoleal]

We, at floresta, have the goal to match the rpc API with Bitcoin Core`s.

And we are actively transitioning to consume Request/Response types from corepc instead of reimplementing it from scratch, but some types are incomplete.

The case im working right now can be served as an example.

For importdescriptors command:

Bitcoin Core expects a

     [ (listof)
       {
         "desc": "str",
         "active": bool,
         "range": n or [n,n],
         "next_index": n,
         "timestamp": timestamp | "now",
         "internal": bool,
         "label": "str",
       },
     ]

Corepc_client(0.10) gives me a

pub struct ImportDescriptorsRequest {
    pub descriptor: String,
    pub timestamp: Value,
}

while i need a more complete such as i implement here in getfloresta/Floresta#675

pub struct DescriptorRequest {
    pub desc: String,
    pub active: bool,
    pub range: DerivationRange,
    pub next_index: Option<u32>,
    pub timestamp: RescanRequest,
    pub internal: bool,
    pub label: String,
}

But this would potentially grow the amount of work to maintain the lib and i not really sure if you guys have that same goal

[tcharding]

Thanks for raising the issue and thanks for using our lib!

So far we have explicitly resisted extensive support for requests i.e any request structs we provide are just what is used by the test client and are in no way meant to be complete.

That said, if you are using the client for integration testing floresta I would imagine you'd want to use RPC methods with all the optional args, right?

If you are using the corepc-client and you'd like to extend it for this usecase I'd be happy to take your PRs. The caveat is that I don't want to make current integration tests super noisy with e.g., a ton on None, None, None, None in every client function call.

One idea would be to add for every client function foo (that takes either no optional args or a subset) an additional function foo_opt that takes all the option args.

How's that sound?

The _opt could be something different. Open to suggestions, something terse I'd say.

[jaoleal]

That said, if you are using the client for integration testing floresta I would imagine you'd want to use RPC methods with all the optional args, right?

Not only for integration testing but for prod also.

How's that sound?

perfect

The _opt could be something different. Open to suggestions, something terse I'd say.

IMHO it works enough, im trying to bot be to picky with names lately 😆.

Ill push a PR soon

[tcharding]

Not only for integration testing but for prod also.

The client in this repo is not for production, it is designed for integration testing only. For prod you should write your own client and/or work with someone to produce a client shared between a few projects. There is an idea to create a prod client in this repo but that work has not yet started.

[jaoleal]

Not only for integration testing but for prod also.

The client in this repo is not for production, it is designed for integration testing only. For prod you should write your own client and/or work with someone to produce a client shared between a few projects. There is an idea to create a prod client in this repo but that work has not yet started.

That shouldnt be a problem for my case since i would only use the types. Ill need to work on corepc-client because for some reason the request types are only availabe there and not on corepc-types.

[tcharding]

Sorry in advance for my overly opinionated views here but IMO your client should define its own request types, the ones in client are just what is needed by that client. I don't want to patch them for other clients and I don't want to put request types in corepc-types because I don't want to provide general purpose request types for the same reasons I don't want to provide a general purpose client.

[jaoleal]

we can say that floresta is building that prod client because floresta-rpc is indeed a client that talks to the floresta rpc server and, given enough compatibility with bitcoin-core, it could be used for that.

Sorry in advance for my overly opinionated views here but IMO your client should define its own request types

Dont need to be sorry, i kinda agree with you because maintaining these types arent easy work but i was seeing this as redudant, for the rust bitcoin ecosystem, since corepc does this job, partially rn.

Ill close this and keep my work there, thanks!

[tcharding]

Thanks man!