Nice big refactoring ;)
What's the underlying motivation, out of curiosity? Just cleaner code, or this will allow to handle something better?

Cleaner code, also it's easier to test interactions with the server if they are separated in logical blocks this way.
With this kind of granularity it should be easier to keep up with server updates and support older server versions too.
The overall idea would be to move the whole communication to DDP (websocket) instead of using some REST API and some websocket API.
This way it wouldn't be necessary to poll for updates (as it's done with the REST API), since the websocket is two ways and the client can get push notifications.
Also the server is smart enough to keep track of what the client knows already, so there's no need to do things like asking for the full room list and filtering the ones the room model knows about already when joining a new room.
I don't know for sure how far back the DDP API goes, but once this implementation is done it should be good enough for most recent servers.

In D29382#662136, @alessandro wrote:

The overall idea would be to move the whole communication to DDP (websocket) instead of using some REST API and some websocket API.
This way it wouldn't be necessary to poll for updates (as it's done with the REST API), since the websocket is two ways and the client can get push notifications.
Also the server is smart enough to keep track of what the client knows already, so there's no need to do things like asking for the full room list and filtering the ones the room model knows about already when joining a new room.
I don't know for sure how far back the DDP API goes, but once this implementation is done it should be good enough for most recent servers.

For sure not we will not switch back to all DDP as we switched from DDP to rest api as RC dev created it as it's faster.
We will continue to switch to RESTAPI not switching back to DDP :)

In D29382#662161, @mlaurent wrote:

In D29382#662136, @alessandro wrote:

The overall idea would be to move the whole communication to DDP (websocket) instead of using some REST API and some websocket API.
This way it wouldn't be necessary to poll for updates (as it's done with the REST API), since the websocket is two ways and the client can get push notifications.
Also the server is smart enough to keep track of what the client knows already, so there's no need to do things like asking for the full room list and filtering the ones the room model knows about already when joining a new room.
I don't know for sure how far back the DDP API goes, but once this implementation is done it should be good enough for most recent servers.

For sure not we will not switch back to all DDP as we switched from DDP to rest api as RC dev created it as it's faster.
We will continue to switch to RESTAPI not switching back to DDP :)

I see. Could you expand a bit your point about performances? Is it a general REST vs websockets assessment, or does it have to do with ruqola's codebase specifically?

In D29382#662268, @alessandro wrote:

I see. Could you expand a bit your point about performances? Is it a general REST vs websockets assessment, or does it have to do with ruqola's codebase specifically?

No it's not ruqola specific it's the RC dev which optimized RC code by using RESTAPI versus DDP api.
They want that we use DDP only for update settings, and use RESTAPI for others methods.
They ported all Rocket.Chat client (web client and apps client) to restapi, and they contacted me 1.5 years to inform me that it was better to use RESTAPI.
It's for that I switched to RESTAPI before all ruqola used DDP directly.