Introduce parse response stack into library

[inaniyants]

First of all I want to mention, that all coming next is just a suggestion, which could be modified or declined via discussion.

Library names itself as SDK, so it could provide developers with richier stack of working with matrix:

• request building ( supports now )
• response handling ( success, errors parsing )
  • parse success results on different structs ( you could see some examples in https://github.com/Voronchuk/ex_matrix_api )
  • parse error results with some more meaningful struct than Tesla has (I mean {:error, any}). And, probably, map it to some known error list (which could be an open source supported reference of matrix errors for every api method)
• context module ( MatrixClient ), which executes given Request with configured default HttpClient and parses a response with default Parser. Any part of this default execution plan could be reconfigured by library user in order to override defaults.

This approach will give matrix_sdk users very comfortable defaults to develop own business logic. And this approach is quite flexible, since every module has it's own separated concern, which could be overridden by library enduser for some exotic cases.

What do you think about this suggestion?

[niklaslong]

I'm fully onboard with this and it would indeed clarify the purpose of the Client module (I'm assuming that's what you meant with MatrixClient ☝️)

[fancycade]

Hi @inaniyants, wanted to chime in and add to your point about response handling. @niklaslong and I have discussing adding something like this that I have been using in the matrix-client (wrapper). Definitely nice to have, not completely sold on my implementation. But we both felt something like this could live in the SDK.

The context module seems like a nice idea. However, I feel like the point of the SDK is to abstract away the annoying HTTP bits, so I'm not sure how necessary this is. Regardless, it will make sense to resolve the client/request dialogue in the other issues before we get to this.

[niklaslong]

Just to clarify, @fancycade has been doing some exploratory work related to higher abstractions around the API. In principle this is a good idea, though it needs to be handled with care to expose a well-constrained error set.

And, probably, map it to some known error list (which could be an open source supported reference of matrix errors for every api method)

@inaniyants Does such a set already exist? Do you already have a sense of what direction you'd like to take with those?

[inaniyants]

@inaniyants Does such a set already exist?

I think there is no such list yet. Only official documentation for some basic errors, like "not found", etc. Probably some error handling could be also found in officially supported matrix clients.

[niklaslong]

Errors are probably simpler to handle than successful responses, given the sheer amount of variety in the latter. Error responses are listed here, which we could simply encapsulate in an API.Error struct following the #78 rename, something like:

defmodule MatrixSDK.API.Error do
  defstruct :code, :message

  # error parsing functions here as well (called based upon the returned status call in the response)
end

The parsing of successful responses is trickier and how to do this well is still an open question for me. A few thoughts here:

• events could be parsed into the existing RoomEvent and StateEvent structs.
• many successful responses return an empty body, returning an empty struct in that case might not be ideal. 🤔
• structs for specific complex responses such as sync may be needed.

As always, I'm open to any thoughts anyone might have!