jsonrpc: add more functions, mostly message related

[Simon-Laux]

No description provided.

[r10s]

for the new BasicChat - where is the line that makes a difference to FullChat?

my advice would be, to make the object clearer, more useful and faster, to draw the line about what should be in and what not by the need of additional database callls:

so, add only add things where ...

• one knows for sure they are always or most times needed whenever a BasicChat object is created
• or things, that do not require additional database calls.

otherwise, things may easily end up in a mess, not much different from FullChat.

concrete, this means to think over adding can_send, profile_image and color - maybe remove them for now and use separate functions instead or re-add them if it turns out they are really needed for the majority of usages of BasicChat. or let the caller use FullChat. it is easier to add a field than to remove one :)

otherwise, we waste up to 3 database calls per load of a BasicChat structure.

also, i would document what makes the difference between BasicChat and FullChat - so future improvements are easier.

apart from these general thoughts, the pr lgtm.

[r10s]

in case, we assume that chat image/color is needed most times BasicChat is created (not so unlikely), this lgtm.

[Jikstra]

for the new BasicChat - where is the line that makes a difference to FullChat?

my advice would be, to make the object clearer, more useful and faster, to draw the line about what should be in and what not by the need of additional database callls:

so, add only add things where ...

* one knows for _sure_ they are _always or most times_ needed whenever a `BasicChat` object is created

* or things, that do not require additional database calls.

otherwise, things may easily end up in a mess, not much different from FullChat.

concrete, this means to think over adding can_send, profile_image and color - maybe remove them for now and use separate functions instead or re-add them if it turns out they are really needed for the majority of usages of BasicChat. or let the caller use FullChat. it is easier to add a field than to remove one :)

otherwise, we waste up to 3 database calls per load of a BasicChat structure.

also, i would document what makes the difference between BasicChat and FullChat - so future improvements are easier.

apart from these general thoughts, the pr lgtm.

Agree with your thoughts, but at the same time it's about porting from js to rust and keeping the refactorings as sane as possible. Also weighting database accesses vs socket overhead I think won't make a big difference. Having the data structure properly modularized in jsonrpc will allow us to have a lot better and clearer overview over the types we use, and also evaluate better ones. But we can do this at any time, also removing properties will not be a problem as deltachat-desktop is the only consumer of this api for now.