Need to clarify when to `sendData:toClient:`

[NicolasAnquetil]

In PLSAbstractServer >> handleRequest:toClient:
the server treats a request from the client and answers it:

• jrpcMessage := self parseJSON: request
• self sendData: (self handleJSON: jrpcMessage) toClient: clientSocket.

For example, <jrpc: #initialize> (first request from client) returns ^ PLSInitializeResult new that is send back to the client by handleRequest:toClient:

But several jrpc handlers also directly call sendData:toClient:

• <jrpc: #'textDocument/didOpen'>

didOpen: textDocument
...
	self sendData: (self convertJRPCJsonableObjectToJSON:
			((JRPCNotificationObject method:
...
				asJRPCJSON)
		toClient: clientOutStream

• <jrpc: #'textDocument/didClose'>
• <jrpc: #'textDocument/didChange'>
  (This case is worse because it may also call didOpen:)
• etc

(they seem to be mostly the ones in the lsp - text synchronisation protocol.

Note that handleJSON: also uses convertJRPCJsonableObjectToJSON: ... asJRPCJSON that we see in the "duplicated" sendData:toClient: calls.

Would be nice to have a clearer definition of who is responsible for sending the answer.
My guess is the handlers should avoid to do it ... ?

[NicolasAnquetil]

Not so simple :-(
I tried to remove sendData:toClient: (and duplicated convertJRPCJsonableObjectToJSON) from didOpen: and just return a JRPCNotificationObject (with a list of diagnostics in this experiment)

But this ends up being transformed in a JRPCEmptyResponseObject in handleJSON: return value and nothing gets sent back to the client.

so it is a bit more complex than it appears
(what a surprise ;-) )

[badetitou]

I should have a deeper look at it.
I know that there is two kind of messages: "notification" and classic message.
I think this is also why sometimes you see jrpc handlers that calls directly sendData:toClient: