Clarify that the current protocol requires that requests and notification are processed in order

[dbaeumer]

The current protocol requires that request and notifications send from the client to the server are processed in the same order as they are sent.

[akosyakov]

@dbaeumer Does it mean that requests and notifications should no be processed concurrently?

In regards to #73. Is it expected that didChange should be processed only after completion is finished successfully or by cancelation from the client?

[bruno-medeiros]

I would suggest that requests should be processed sequentially as far as the client can tell, but internally they can be processed concurrently if it is guaranteed the result is the same as if they were processed sequentially. For example mutiple read-only/query operations can be processed concurrently, obviously.

As for mixing read-only and write operations (like didChange), for example in the scenario @akosyakov mentioned above: if a didChange request cames after a completion request, the server can just automatically cancel the previous completion (and all other pending queries), thus ensuring sequentiality.

If we wanted to get smart, the server could try to detect if the didChange actually affects the previous completion request, but I imagine for 99.9% of user IDE cases, it does invalidate the previous request, so there is really little value in the server trying to be this smart. (plus it might complicate LSP protocol implementation)