Missing/Cleanup Services

[bmarty]

Following what has been done in #5858, there is some cleanup to do in our Services API. The SDK should provide a high level and grouped API by functionality. Some new functionalities have been added without really following this rule.

What is missing, at a Session level:

• A SyncService. Move some methods that are defined directly to the Session. There is a clash name with an existing SyncService :/. Not sure how to handle that, if we can keep 2 things with the same name (not ideal) or rename some.

What is missing, at a Room level:

• A PollService, to be able to create poll, vote, edit, and close a poll
• A LocationSharingService, to be able to send a static location, start a live location sharing, send location during a live location sharing, and stop a live location sharing. Today the app has to send state event and location event, this not high level enough
• An EditionService, to be able to edit any Event. Could also include the redaction of an Event. Also the API editTextMessage and other similar API are taking a TimelineEvent as a parameter, I think it could be better if an eventId is used instead. The SDK can get the TimelineEvent from the eventId if necessary (using TimelineEventDataSource)
• Clarify ThreadsLocalService and ThreadsService and maybe merge them together and let the SDK do its best depending on the server capability?
• Other ?

This issue is just a matter of reorganize our API, no new code should be necessary.

Better to handle it when #5858 has been merged.

[ariskotsomitopoulos]

Regarding ThreadsLocalService and ThreadsService. It is quite challenging to make them exist in parallel while we had to persist the old schema ( for old clients ) and also create a new one. At first I tried having a common interface with generics that will return different objects/types but it was not that clear as a solution.

As times goes by ThreadsLocalService should be deprecated while almost all servers will support threads. But I agree definitely it is not ideal. The idea was that ThreadsLocalService would be temporarily, so it would be quite simple to remove it like that. However, it seems that we will never be 100% precent about what the home servers supports, so maybe a refactor there is worth it