All request/response URIs should be relative to rootPath about language-server-protocol HOT 13 CLOSED

When we designed the protocol we made all URIs absolute due to the following reasons:

• VS Code can operate on a single file without a workspace (it is undefined in this case). So here the URI must be absolute
• Languages could reference resources outside of the workspace and these resource could on Window even be on another drive.

All I can recommend for your use case is to make them relative yourself and disable the server if VS Code opens on a single file.

Any objection to close the request.

from language-server-protocol.

What I like about absolute URIs is that they are canonical. You can use them as a key in a symbol index for example. Also, you need to support different protocols (inmemory:, file://, ftp://, git://, ...) and you cannot make a relative file:// URI because the path would be taken as the host.

Therefore, I'd assume that there should always be a rootPath known that you can always resolve on?

It can be undefined.

from language-server-protocol.

OK, what about if the specification allowed for the URIs to be absolute OR relative, and it's up to the implementor to make relative URIs absolute by resolving them against the rootPath?

We'd love to be able to use any language-server in the manner that I describe in the body of this issue, as opposed to only being able to use implementations that we write. For example, we'd like to able to use the existing vscode-javac implementation after contributing a patch to make it resolve relative URIs against the rootPath.

This change seems non breaking since it would allow VS Code to still do as you describe (open single files / resources outside the workspace).

If you don't wish to support this, I think it would be worth making this clear in the protocol specification (i.e. all URIs are absolute for these reasons).

from language-server-protocol.

Note for context, we're thinking of contributing the following implementations:

• Groovy
• Python
• SQL

All of these will have the behaviour I describe in my comment above so it would be nice if it was part of the spec :)

from language-server-protocol.

Interesting idea. Some initial thoughts about it:

• what would be the behavior of receiving a relative URI without knowing about a base (e.g. workspace folder). Will the request error.
• since a URI would be either relative or absolute the server needs to be able to handle both cases. The server could be used in editor one sending absolute URIs and in editor two sending relative URIs. So the win for the server is that in responses or requests he sends URIs can be relative.
• on the VSCode client side we could have hooks in the LanguageClient to transform the URIs.

Needs more thinking.

from language-server-protocol.

Sweet!

On your first point, not exactly sure of the case your describing. The protocol states:

The initialize request is sent as the first request from the client to the server.

Therefore, I'd assume that there should always be a rootPath known that you can always resolve on?

from language-server-protocol.

Some clients (notably Eclipse) have a notion of workspace (=root) that isn't really tied to a folder. Projects in it can be located anywhere and the projects may contained "linked resourced" (i.e. Eclipse-specific soft-links). So absolute URIs are a must.

from language-server-protocol.

Also, absolute URI doesn't mean you have to leak your rootPath. You could come up with your totally own URI scheme that is in no way related to the rootPath, like VS Code does for unsaved files.

from language-server-protocol.

Yes, but unless I'm too tired to think straight, a custom URI scheme means that the client can't be generic because it needs to know with which server to use which scheme and how to map it to real files. A generic client is a big bonus. I think this is a different issue, so I will open a new ticket.

from language-server-protocol.

Or maybe I got it all wrong and the URIs are handled by the servers as opaque identifiers? Since the server doesn't access the files and might not even understand the scheme, it feels reasonable.

from language-server-protocol.

OK, so sounds like changing the spec so that all paths are absolute is a no-go. But changing it so that URIs can be relative seems reasonable (and are a requirement when running language servers in the cloud). Sure, you could come up with your own scheme, but then all language servers you want to use must support this scheme.

from language-server-protocol.

@jared2501 why exactly is it a requirement when running language servers in the cloud?

from language-server-protocol.

With the introduction of workspace folders I think having them absolute is the right thing to do. Otherwise we would now make them relative to a workspace folder which would need to be sent as well.

I will close the issue since I don't see changing this in the protocol in the near future.

If you disagree and feel that this issue is crucial: we’re happy to listen and to reconsider.

from language-server-protocol.