On Tue, 4 Oct 2022, Wayne Sherman wrote:
Michael wrote:
Seems like both parts in the LSP protocol are playing 'client' and 'server',
because:
"The Client is defined as the origin of Request objects and the handler of
Response objects.
The Server is defined as the origin of Response objects and the handler of Request
objects."
As usual one can trust Microsoft to give an own interpretation to a protocol :)
The JSON-RPC protocol defines client and server strictly by who sends
the request and who handles the response. An endpoint can be both a
client and server at the same time over the same connection if the
transport permits. For example, Endpoint-1 connects to Endpoint-2
using a standard TCP socket or UNIX socket. Endpoint-1 is a
"JSON-RPC" client when it sends a request, and Endpoint-2 is a
"JSON-RPC" server when it receives the request and sends a response.
But when Endpoint-2 initiates a request to Endpoint-1 over the same
connection, Endpoint-2 is a "JSON-RPC" client and Endpoint-1 is a
"JSON-RPC" server (i.e. the roles have switched, which is not
prohibited by the protocol). After the definition of client/server
the spec says:
"One implementation of this specification could easily fill both of
those roles, *even at the same time*, to other different clients or the
same client"
No doubt, but I've never seen this in practice.
Not surprising, since HTTP is the dominant protocol.
But as said, if we can extend the implementation to support other
transports which do allow bi-directional sending of requests,
then I am all for it.
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
