[Tech Debt] Refactor the TCP and STDIO servers, protocols and handlers #193
Comments
glennsarti
added a commit
to glennsarti/puppet-editor-services
that referenced
this issue
Nov 1, 2019
The ruby standard is to use snake-case not kebab-case for namespaces. This commit renames the puppet-editor-services directory to puppet_editor_services.
glennsarti
added a commit
to glennsarti/puppet-editor-services
that referenced
this issue
Nov 1, 2019
Previously the both the Editor Services and Language Server have grown
organically over time. It is now complicated to understand how the Server,
Client connection and message routing work as their scopes have been bleeding
into other domains. For example the message_router also can send JSON RPC
messages.
This commit changes the architecture of the Editor Services and the Language
Server to use much cleaner architecture.
Note that the refactor should only touch from the Message Router down to the
Server level (e.g. TCP server). The Validation Queue is modified as it calls
back into the server due to async. processing.
The new architecture moves the ALL of the following into the Puppet Editor
Services namespace:
Server <--> Connection <--> Protocol <--> Handler
- The Server is responsible for sending and receiving "bytes-on-the-wire" (TCP,
STDIO)
- The Connection is created per client and manages the connection to the client
(e.g. close/error) The connection sends and receives arrays of bytes to/from
the Protocol object
- The Protocol object is responsible for receiving bytes from the Connection and
coverting them into messages, and vice-versa (turning messages into byte
arrays to the connection)
- The Handler reads and writes messages to/from the protocol.
There will normally be one object-chain per connection e.g. For three connections;
+- Connection -- Protocol -- Handler
|
Server -+- Connection -- Protocol -- Handler
|
+- Connection -- Protocol -- Handler
For the purposes of the Language and Debug Server, Only the JSON RPC protocol
and base JSON RPC handler are implemented.
The Language Server then implements it's own Handler in the Puppet Language Server namespace:
Language Server Handler <--> Puppet Providers/Helpers etc.
* This handler takes messages, processes them and optionally sends a reply.
* Note that the complex server-to-client request/response process is handled by
the JSON RPC protocol layer.
glennsarti
added a commit
to glennsarti/puppet-editor-services
that referenced
this issue
Nov 1, 2019
Previously the both the Editor Services and Language Server have grown
organically over time. It is now complicated to understand how the Server,
Client connection and message routing work as their scopes have been bleeding
into other domains. For example the message_router also can send JSON RPC
messages.
This commit changes the architecture of the Editor Services and the Language
Server to use much cleaner architecture.
Note that the refactor should only touch from the Message Router down to the
Server level (e.g. TCP server). The Validation Queue is modified as it calls
back into the server due to async. processing.
The new architecture moves the ALL of the following into the Puppet Editor
Services namespace:
Server <--> Connection <--> Protocol <--> Handler
- The Server is responsible for sending and receiving "bytes-on-the-wire" (TCP,
STDIO)
- The Connection is created per client and manages the connection to the client
(e.g. close/error) The connection sends and receives arrays of bytes to/from
the Protocol object
- The Protocol object is responsible for receiving bytes from the Connection and
coverting them into messages, and vice-versa (turning messages into byte
arrays to the connection)
- The Handler reads and writes messages to/from the protocol.
There will normally be one object-chain per connection e.g. For three connections;
+- Connection -- Protocol -- Handler
|
Server -+- Connection -- Protocol -- Handler
|
+- Connection -- Protocol -- Handler
For the purposes of the Language and Debug Server, Only the JSON RPC protocol
and base JSON RPC handler are implemented.
The Language Server then implements it's own Handler in the Puppet Language Server namespace:
Language Server Handler <--> Puppet Providers/Helpers etc.
* This handler takes messages, processes them and optionally sends a reply.
* Note that the complex server-to-client request/response process is handled by
the JSON RPC protocol layer.
glennsarti
added a commit
to glennsarti/puppet-editor-services
that referenced
this issue
Nov 7, 2019
The ruby standard is to use snake-case not kebab-case for namespaces. This commit renames the puppet-editor-services directory to puppet_editor_services.
glennsarti
added a commit
to glennsarti/puppet-editor-services
that referenced
this issue
Nov 7, 2019
Previously the both the Editor Services and Language Server have grown
organically over time. It is now complicated to understand how the Server,
Client connection and message routing work as their scopes have been bleeding
into other domains. For example the message_router also can send JSON RPC
messages.
This commit changes the architecture of the Editor Services and the Language
Server to use much cleaner architecture.
Note that the refactor should only touch from the Message Router down to the
Server level (e.g. TCP server). The Validation Queue is modified as it calls
back into the server due to async. processing.
The new architecture moves the ALL of the following into the Puppet Editor
Services namespace:
Server <--> Connection <--> Protocol <--> Handler
- The Server is responsible for sending and receiving "bytes-on-the-wire" (TCP,
STDIO)
- The Connection is created per client and manages the connection to the client
(e.g. close/error) The connection sends and receives arrays of bytes to/from
the Protocol object
- The Protocol object is responsible for receiving bytes from the Connection and
coverting them into messages, and vice-versa (turning messages into byte
arrays to the connection)
- The Handler reads and writes messages to/from the protocol.
There will normally be one object-chain per connection e.g. For three connections;
+- Connection -- Protocol -- Handler
|
Server -+- Connection -- Protocol -- Handler
|
+- Connection -- Protocol -- Handler
For the purposes of the Language and Debug Server, Only the JSON RPC protocol
and base JSON RPC handler are implemented.
The Language Server then implements it's own Handler in the Puppet Language Server namespace:
Language Server Handler <--> Puppet Providers/Helpers etc.
* This handler takes messages, processes them and optionally sends a reply.
* Note that the complex server-to-client request/response process is handled by
the JSON RPC protocol layer.
glennsarti
added a commit
to glennsarti/puppet-editor-services
that referenced
this issue
Nov 7, 2019
… Server
Previously the the Editor Services, Language and Debug Servers have grown
organically over time. It is now complicated to understand how the Server,
Client connection and message routing work as their scopes have been bleeding
into other domains. For example the message_router also can send JSON RPC
messages.
This commit changes the architecture of the Editor Services, Language and Debug
Servers to use much cleaner architecture.
Note that the refactor should only touch from the Message Router down to the
Server level (e.g. TCP server). The Validation Queue is modified as it calls
back into the server due to async. processing.
The new architecture moves the ALL of the following into the Puppet Editor
Services namespace:
Server <--> Connection <--> Protocol <--> Handler
- The Server is responsible for sending and receiving "bytes-on-the-wire" (TCP,
STDIO)
- The Connection is created per client and manages the connection to the client
(e.g. close/error) The connection sends and receives arrays of bytes to/from
the Protocol object
- The Protocol object is responsible for receiving bytes from the Connection and
coverting them into messages, and vice-versa (turning messages into byte
arrays to the connection)
- The Handler reads and writes messages to/from the protocol.
There will normally be one object-chain per connection e.g. For three connections;
+- Connection -- Protocol -- Handler
|
Server -+- Connection -- Protocol -- Handler
|
+- Connection -- Protocol -- Handler
For the purposes of the Language Server, only the JSON RPC protocol and base
JSON RPC handler are implemented. The Language Server then implements it's own
Handler in the Puppet Language Server namespace:
Language Server Handler <--> Puppet Providers/Helpers etc.
* This handler takes messages, processes them and optionally sends a reply.
* Note that the complex server-to-client request/response process is handled by
the JSON RPC protocol layer.
For the purposes of the Debug Server, only the DAP (Debug Adapter Protocol)
protocol and base Debug Adapter handler are implemented. The Debug Server then
implements it's own Handler in the Puppet Debug Server namespace:
Debug Server Handler <--> Puppet Debug Sesssion Providers/Helpers etc.
* This handler takes messages, processes them and optionally sends a reply.
glennsarti
added a commit
to glennsarti/puppet-editor-services
that referenced
this issue
Nov 8, 2019
… Server
Previously the the Editor Services, Language and Debug Servers have grown
organically over time. It is now complicated to understand how the Server,
Client connection and message routing work as their scopes have been bleeding
into other domains. For example the message_router also can send JSON RPC
messages.
This commit changes the architecture of the Editor Services, Language and Debug
Servers to use much cleaner architecture.
Note that the refactor should only touch from the Message Router down to the
Server level (e.g. TCP server). The Validation Queue is modified as it calls
back into the server due to async. processing.
The new architecture moves the ALL of the following into the Puppet Editor
Services namespace:
Server <--> Connection <--> Protocol <--> Handler
- The Server is responsible for sending and receiving "bytes-on-the-wire" (TCP,
STDIO)
- The Connection is created per client and manages the connection to the client
(e.g. close/error) The connection sends and receives arrays of bytes to/from
the Protocol object
- The Protocol object is responsible for receiving bytes from the Connection and
coverting them into messages, and vice-versa (turning messages into byte
arrays to the connection)
- The Handler reads and writes messages to/from the protocol.
There will normally be one object-chain per connection e.g. For three connections;
+- Connection -- Protocol -- Handler
|
Server -+- Connection -- Protocol -- Handler
|
+- Connection -- Protocol -- Handler
For the purposes of the Language Server, only the JSON RPC protocol and base
JSON RPC handler are implemented. The Language Server then implements it's own
Handler in the Puppet Language Server namespace:
Language Server Handler <--> Puppet Providers/Helpers etc.
* This handler takes messages, processes them and optionally sends a reply.
* Note that the complex server-to-client request/response process is handled by
the JSON RPC protocol layer.
For the purposes of the Debug Server, only the DAP (Debug Adapter Protocol)
protocol and base Debug Adapter handler are implemented. The Debug Server then
implements it's own Handler in the Puppet Debug Server namespace:
Debug Server Handler <--> Puppet Debug Sesssion Providers/Helpers etc.
* This handler takes messages, processes them and optionally sends a reply.
5 tasks
glennsarti
added a commit
that referenced
this issue
Nov 13, 2019
(GH-193) Refactor Editor Services and Language Server
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The Puppet Editor Services - Server, Connection, Protocol and Handler have organically grown and are now a gnarled mess. Time to pay down some of the tech debt.
Refactor the from message-router down in the stack.
The text was updated successfully, but these errors were encountered: