3 ms·

The proposal is to split the LSP implementation into a transport layer and a logical layer. The current LSP implementation is directly tied to JSON-RPC. Apple'

The proposal is to split the LSP implementation into a transport layer and a logical layer. The current LSP implementation is directly tied to JSON-RPC. Apple's end goal is, as you say, to get clangd to work with Xcode. However, having a replaceable transport layer for LSP could benefit lots of people other than Apple.

DannyBee 9y ago
Sure, it's nice, but again, being pragmatic, nobody else has desired such a thing that much. Ie so far the "lots of people" have not materialized, even outside clangd. I can certainly think of use cases for such a thing, but most people seem happy enough with json-rpc at the moment. Part of that is likely that trying to speak LSP over a non local connection may be a fools errand anyway. It's a chatty protocol no matter what the transport.
- oflannabhra 9y ago
  Just because Apple is the first doesn't mean there won't be others. Maybe others have not materialized because the upfront cost of updating clangd was judged too high. JSON-RPC has several alternatives that very large software companies have vested interests in: gRPC and XPC. You seem more knowledgeable of these technologies than I am, though. It just seems to me a good thing that 1) Apple, and consequently, all iOS and macOS developers will be using clangd, and 2) Apple is putting significant effort into improving clangd. I'm not sure why any of that news or optimism needs to be quenched.
  - DannyBee 9y ago
    My point was precisely that plenty of languages have LSP implementations at this point, an f even in those, nobody has cared much to try to find an alternative to json rpc. As for 2, all I'll say is based on history in llvm projects, I'm not anywhere near as optimistic as you. The history here is simply not one of all great things. The PR is, but the reality is much more mixed (some really great things, some really not so great). So while I certainly am hopeful, it's definitely not the unbridled optimism everyone displays here.
    - kenferry 9y ago
      You don't think apple's support of llvm and clang has been important to the project? That's REALLY pushing it.
      - DannyBee 9y ago
        That's not what i said at all. I said some things have been really great, some really not so great. This isn't even a controversial view among long-time llvmers. Heck, last time i asked him (a few months ago), even Chris Lattner agreed with my view, and he used to run his stuff at Apple, so i don't think it's unreasonable. I think it's perfectly okay to be cautiously optimistic instead of fawningly happy. Do you actually have data or a real argument you'd like to use to suggest otherwise (IE that it's been all overwhelmingly positive?)
    - r4nt3r 9y ago
      While I agree that not everything is always great, I'd say the same for our own contributions ;) I've definitely let patches unreviewed for way too long due to internal priorities, and have gotten my share of shit at conferences for that... In this case, the collaboration with Apple and Ericsson on the underlying architecture has been going on for a while, and while not everybody always agrees on priorities and design details, I'm thrilled to see Apple double down on their involvement here!
- k4st 9y ago
  The [follow up](http://lists.llvm.org/pipermail/cfe-dev/2018-April/057672.html http://lists.llvm.org/pipermail/cfe-dev/2018-April/057672.ht...) message suggests that Google already internally using a non-JSPN-RPC transport layer.
  - DannyBee 9y ago
    Yeah, but that is likely to actually go away, not happen more. It's not a desired thing in that case, it was just easiest at the time for various reasons. We didn't want the public project to have to support our special snowflakism, hence it was done a different way.
    - r4nt3r 9y ago
      clangd already has a layered architecture, where you can either use the JSON-RPC mechanism or more directly control clangd and implement your own transport. There are no plans for this to go away, as generally large companies often have environments in which they want better control of features than a standard protocol like LSP can give you, and we don't discourage that. We also just talked with Apple folks at Euro LLVM about this, and while the plan for the near future is for them to have a transport conversion to JSON-RPC, I expect them to want the more fine grained control in the long term.
- luikore 9y ago
  Really? I desire a protocol which is not coupled with JSON-RPC.

DannyBee 9y ago

Sure, it's nice, but again, being pragmatic, nobody else has desired such a thing that much. Ie so far the "lots of people" have not materialized, even outside clangd. I can certainly think of use cases for such a thing, but most people seem happy enough with json-rpc at the moment. Part of that is likely that trying to speak LSP over a non local connection may be a fools errand anyway. It's a chatty protocol no matter what the transport.

oflannabhra 9y ago
Just because Apple is the first doesn't mean there won't be others. Maybe others have not materialized because the upfront cost of updating clangd was judged too high. JSON-RPC has several alternatives that very large software companies have vested interests in: gRPC and XPC. You seem more knowledgeable of these technologies than I am, though. It just seems to me a good thing that 1) Apple, and consequently, all iOS and macOS developers will be using clangd, and 2) Apple is putting significant effort into improving clangd. I'm not sure why any of that news or optimism needs to be quenched.
- DannyBee 9y ago
  My point was precisely that plenty of languages have LSP implementations at this point, an f even in those, nobody has cared much to try to find an alternative to json rpc. As for 2, all I'll say is based on history in llvm projects, I'm not anywhere near as optimistic as you. The history here is simply not one of all great things. The PR is, but the reality is much more mixed (some really great things, some really not so great). So while I certainly am hopeful, it's definitely not the unbridled optimism everyone displays here.
  - kenferry 9y ago
    You don't think apple's support of llvm and clang has been important to the project? That's REALLY pushing it.
    - DannyBee 9y ago
      That's not what i said at all. I said some things have been really great, some really not so great. This isn't even a controversial view among long-time llvmers. Heck, last time i asked him (a few months ago), even Chris Lattner agreed with my view, and he used to run his stuff at Apple, so i don't think it's unreasonable. I think it's perfectly okay to be cautiously optimistic instead of fawningly happy. Do you actually have data or a real argument you'd like to use to suggest otherwise (IE that it's been all overwhelmingly positive?)
  - r4nt3r 9y ago
    While I agree that not everything is always great, I'd say the same for our own contributions ;) I've definitely let patches unreviewed for way too long due to internal priorities, and have gotten my share of shit at conferences for that... In this case, the collaboration with Apple and Ericsson on the underlying architecture has been going on for a while, and while not everybody always agrees on priorities and design details, I'm thrilled to see Apple double down on their involvement here!
k4st 9y ago
The [follow up](http://lists.llvm.org/pipermail/cfe-dev/2018-April/057672.html http://lists.llvm.org/pipermail/cfe-dev/2018-April/057672.ht...) message suggests that Google already internally using a non-JSPN-RPC transport layer.
- DannyBee 9y ago
  Yeah, but that is likely to actually go away, not happen more. It's not a desired thing in that case, it was just easiest at the time for various reasons. We didn't want the public project to have to support our special snowflakism, hence it was done a different way.
  - r4nt3r 9y ago
    clangd already has a layered architecture, where you can either use the JSON-RPC mechanism or more directly control clangd and implement your own transport. There are no plans for this to go away, as generally large companies often have environments in which they want better control of features than a standard protocol like LSP can give you, and we don't discourage that. We also just talked with Apple folks at Euro LLVM about this, and while the plan for the near future is for them to have a transport conversion to JSON-RPC, I expect them to want the more fine grained control in the long term.
luikore 9y ago
Really? I desire a protocol which is not coupled with JSON-RPC.