8000 Split the generic lsp-like backend from the lsp-specific implementation · Issue #391 · ebkalderon/tower-lsp · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Split the generic lsp-like backend from the lsp-specific implementation #391

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
agluszak opened this issue Mar 22, 2023 · 2 comments
Open
8000

Comments

@agluszak
Copy link
Contributor
agluszak commented Mar 22, 2023

Hi! I'd like to write a rust library for Build Server Protocol I co-maintain at JetBrains. I could fork tower-lsp, but it turns out that the implementation is pretty much generic and could be used for any JSON-RPC, LSP-like protocol (which BSP happens to be). I propose to split this crate into two: tower-lsp and tower-lsp-backend (or tower-lsp-like, tower-lsp-generic). The first one would depend on and use the lsp_types crate, the other one would just provide the "backend" for it.

@agluszak agluszak changed the title Split the generic lsp-like implementation from the lsp-specific one Split the generic lsp-like backend from the lsp-specific implementation Mar 22, 2023
@agluszak
Copy link
Contributor Author

I'm implementing a prototype of how that could look like

@ebkalderon
Copy link
Owner

Interesting! It sounds like you might be looking to extract the JSON-RPC machinery out of tower-lsp into a separate crate. Is this understanding accurate? If so, that sounds like a pretty interesting idea. Granted, the internal Router is tightly coupled to the Language Server Protocol (on purpose, to be as fast and no-frills as possible), but I think it would be neat to pull it out to another crate someday. ☺️

To play devil's advocate, though: considering the limitations of the current implementation (e.g. #284) and significant changes planned for this library in the future, I worry that extracting the JSON-RPC stuff outside tower-lsp at this stage might make it harder to iterate and fix bugs in the future. That's not to say I'm against the idea, though! I wouldn't mind seeing this happen eventually, so feel free to share your prototype here if you'd like.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants
0