LSPS0 message handling #4
Conversation
|
Ok, addressed all of your comments and updated CI to run against 1.48.0 successfully. |
There was a problem hiding this comment.
Sorry for the delay here. Generally it's great that we're separating layers now, but I'm still a bit confused about the current design.
In particular I'm not entirely sure if there is no way around splitting TransportMessageHandler and ProtocolMessageHandler? Also, all of this needs docs, which would make it a lot clearer and would also help think about it further.
|
I made the minor nit doc changes and linked where made sense. I added a little bit more information to LSPManager around expected usage. The problem is that in this version there's really no real use without any of the protocols added. There's no events or even public api to use. The only outstanding "issue" imo is naming. The only exposed objects are the LSPConfig and LSPManager. "LSP" typically refers to the server, the one doing the providing. I think you said the spec uses "lsp" and "client". The challenge is currently there is a singular config/'manager' for both use cases. I don't think the LSP prefixed words are the worst but am open to suggestions if you have some. I could see maybe moving to using a word like Liquidity instead of LSP but I think an "LSP" encompasses more than just liquidity. |
|
I think we need to incorporate this fix also to unbreak CI: lightningdevkit/rust-lightning#2353 |
CustomMessageHandler that implements the transport layer to be used as basis for future LSP protocol implementations
Implements LSPS0 message handling and lays groundwork for other LSPS protocol handling.