Skip to content
This repository has been archived by the owner on Jun 26, 2018. It is now read-only.

Spec JSON format for loading #7

Closed
octref opened this issue Jun 18, 2018 · 6 comments
Closed

Spec JSON format for loading #7

octref opened this issue Jun 18, 2018 · 6 comments

Comments

@octref
Copy link
Owner

octref commented Jun 18, 2018

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

@octref
Copy link
Owner Author

octref commented Jun 20, 2018

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
Copy link
Owner Author

octref commented Jun 20, 2018

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.

@dbaeumer
Copy link

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
Copy link
Owner Author

octref commented Jun 20, 2018

OK, sounds good.

@octref
Copy link
Owner Author

octref commented Jun 26, 2018

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

@octref
Copy link
Owner Author

octref commented Jun 26, 2018

This issue was moved to microsoft/language-server-protocol-inspector#7

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants