The gaol why we need to determine what ID should be used as stanza-id,
is so we can use the stanza-id in the future for deduplication.
Case we are the sender:
Either we look for a origin-id element, which we will include in the
Future in all messages we send, or until then the ID we set on the
message as attr.
Case we are the receiver:
If our server supports mam:2 we take the ID of the result element,
because mam:2 injects the archive ID live into every message we
receive. If we dont have mam:2 we fall back to the ID of the message
attr.
- Refactor and clean up code around MamMessageReceivedEvent
- Goal is to add a GcMamMessageReceivedEvent later on
- For that cause added a raw-mam-message-received base event
The purpose of
`if version and not gajim.contacts.get_contacts_jid_list()`
seemed to be that when cache.db is empty (maybe it was deleted)
`gajim.contacts.get_contacts_jid_list()` should come back empty.
So on an empty roster cache, version was set to None, so that we
request in any case a new roster.
The Problem is that `gajim.contacts.get_contacts_jid_list()` is not
a good indication for an empty cache.db. On start we trigger a
`RosterReceivedEvent` which does a DB query to get the roster. Even
if that DB query comes up empty, the Event is still pushed.
In the event handler `_nec_roster_received` in roster_window.py we
add then previously open controls and our self (if the option is set)
to the roster, making `gajim.contacts.get_contacts_jid_list()` return
these contacts and hence the condition in `request_roster()` always
False.
So the version is set in the roster request, and if there is no new
version on the server, we request no new roster even though we only
have ourself and previously open controls in our roster.
As a solution for this we delete the roster version from the config
in `RosterReceivedEvent` if the DB query comes back empty, which
triggers a new roster request.
Yann Leboulanger
Philipp Hörist
André Apitzsch