Spec JSON format for loading

[octref]

From @octref on June 18, 2018 7:50

Specify a JSON format which the Inspector could load.
Stay close to the original LSP JSON format, but add useful fields such as timestamp.

Copied from original issue: octref/lsp-inspector#7

[octref]

After reading the LSP spec, it seems to me that the spec is designed so that these types can be deduced from reading the parameters.

• Request (id + method)
• Response (id + result / error)
• Notification (method without id)

Therefore, a generic interface for them is enough

interface LSPMessage extends Message {
  id?: number | string | null;
  result?: any;
  error?: ResponseError<any>;
  params?: any
}

However, these more detailed types cannot be deduced, as we don't know if a communication is from client to server, or from server to client. Those can only be determined if you decide a perspective, such as from client side or the server side.

• Send Notification
• Receive Notification
• Send Request
• Receive Response
• Receive Request
• Send Response

In the docs, I'll make it clear that the log and the visualization are perspectives from the client side.

For the types, I think something like this will do:

export type LogMessageType =
  | 'send-notification'
  | 'recv-notification'
  | 'send-request'
  | 'recv-request'
  | 'send-response'
  | 'recv-response'

interface LogMessage extends Message {
  type: LogMessageType;
  timestamp: number; // Unix timestamp
  id?: number | string | null;
  result?: any;
  error?: ResponseError<any>;
  params?: any;
}

@dbaeumer What do you think?

[octref]

Also think we should use https://en.wikipedia.org/wiki/JSON_streaming#Line-delimited_JSON for logging. This way it's easy to append to the log. Parsing is also easy - splitting the content by \r\n and read/validate each JSON object according to the LogMessage interface.

[octref]

From @dbaeumer on June 20, 2018 9:31

Actually I would make this a composite not a sub type and would reuse the stuff we have in the jsonrpc module if possible since the definitions need to go into the tracer as well.

Something like this:

interface LogEntry {
   type: LogMessageType;
   message: RequestMessage | ResponseMessage | NotificationMessage;
   timestamp: number;
}

[octref]

OK, sounds good.

[octref]

This is captured by #8 and microsoft/vscode-languageserver-node#366.