Implementation contains unneeded code #139
Comments
guusdk
added a commit
to guusdk/openfire-monitoring-plugin
that referenced
this issue
Dec 2, 2020
…chivedMessage (almost) immutable No functional changes intended.
guusdk
added a commit
to guusdk/openfire-monitoring-plugin
that referenced
this issue
Dec 2, 2020
Reduce code complexity by removing code that is not used.
guusdk
added a commit
to guusdk/openfire-monitoring-plugin
that referenced
this issue
Dec 2, 2020
…ceManager PersistenceManager had a lot of definition that wasn't used. It either had no implementation, or the little implementation that was there, went unreferenced. This commit removes it all, reducing code complexity by a significant factor. It appears to me that all removed code was replaced by code in the implementation of ConversationManager - although I'm not 100% sure.
guusdk
added a commit
to guusdk/openfire-monitoring-plugin
that referenced
this issue
Dec 2, 2020
Removing code that is not referenced / used anywhere. This reduces complexity, and improves maintainability.
guusdk
added a commit
to guusdk/openfire-monitoring-plugin
that referenced
this issue
Dec 2, 2020
Removing code that is not referenced / used anywhere. This reduces complexity, and improves maintainability.
guusdk
added a commit
to guusdk/openfire-monitoring-plugin
that referenced
this issue
Dec 2, 2020
This adds documentation that helps define how ArchivedMessage is to be used.
guusdk
added a commit
to guusdk/openfire-monitoring-plugin
that referenced
this issue
Dec 2, 2020
When a previously archived message is being retrieved, the optional 'stanza' database value is eventually parsed as XMPP. This commit brings forward this process (to a place immediately after the data is obtained from the database), replacing the existing mechanism that did it just before the message was being routed to the intended recipient. The benefit of this is that the code that it is more fail-fast, and operations that follow the database retrieval can work with a proper stanza, instead of having to work with its String representation. This brings type-safety. Lastly, there's less ambiguity around where parsing occurs (and at what point the parsing can be expected to have been completed).
guusdk
added a commit
to guusdk/openfire-monitoring-plugin
that referenced
this issue
Dec 2, 2020
…rection' The concept of 'direction' of an ArchivedMessage is, to some, counter-intuitive. The mechanism that determines the direction of a particular stanza should be centralized to reduce confusion.
guusdk
added a commit
to guusdk/openfire-monitoring-plugin
that referenced
this issue
Dec 2, 2020
When processing an archived message in MAM context, using the 'with' attribute (that would otherwise go unused) to reflect the nickname of the sender of the message allows us to avoid unneeded stanza parsing.
guusdk
added a commit
to guusdk/openfire-monitoring-plugin
that referenced
this issue
Dec 2, 2020
…tanza IDs Code duplication (and thus complexity) is reduced by centralizing where an appropriate stanza ID is obtained.
Fishbowler
added a commit
to guusdk/openfire-monitoring-plugin
that referenced
this issue
Dec 4, 2020
…lt ID The implementation looks for a stanza-id and falls back to a database ID. The XEP-0313 says a client shouldn't rely on the stanza-id as the UID of a message in the archive, but OF is trending towards making that reliable. In the meantime, the result ID is still the database ID. Without this change, searches for the database ID is searched as freetext within the stanza. As a short number in amongst many GUIDs, false positives are more likely than not. This change ensures that a search for a stanza-id is more likely to match exactly that, but it's not foolproof.
Fishbowler
added a commit
to guusdk/openfire-monitoring-plugin
that referenced
this issue
Dec 7, 2020
…lt ID The implementation looks for a stanza-id and falls back to a database ID. The XEP-0313 says a client shouldn't rely on the stanza-id as the UID of a message in the archive, but OF is trending towards making that reliable. In the meantime, the result ID is still the database ID. Without this change, searches for the database ID is searched as freetext within the stanza. As a short number in amongst many GUIDs, false positives are more likely than not. This change ensures that a search for a stanza-id is more likely to match exactly that, but it's not foolproof.
Fishbowler
added a commit
to guusdk/openfire-monitoring-plugin
that referenced
this issue
Dec 8, 2020
…lt ID The implementation looks for a stanza-id and falls back to a database ID. The XEP-0313 says a client shouldn't rely on the stanza-id as the UID of a message in the archive, but OF is trending towards making that reliable. In the meantime, the result ID is still the database ID. Without this change, searches for the database ID is searched as freetext within the stanza. As a short number in amongst many GUIDs, false positives are more likely than not. This change adds to the defense against false positives and ensures that a search for a stanza-id is more thoroughly checked to be the one we were looking for.
guusdk
added a commit
that referenced
this issue
Dec 8, 2020
Reduce code complexity by removing code that is not used.
guusdk
added a commit
that referenced
this issue
Dec 8, 2020
PersistenceManager had a lot of definition that wasn't used. It either had no implementation, or the little implementation that was there, went unreferenced. This commit removes it all, reducing code complexity by a significant factor. It appears to me that all removed code was replaced by code in the implementation of ConversationManager - although I'm not 100% sure.
guusdk
added a commit
that referenced
this issue
Dec 8, 2020
Removing code that is not referenced / used anywhere. This reduces complexity, and improves maintainability.
guusdk
added a commit
that referenced
this issue
Dec 8, 2020
Removing code that is not referenced / used anywhere. This reduces complexity, and improves maintainability.
guusdk
added a commit
that referenced
this issue
Dec 8, 2020
This adds documentation that helps define how ArchivedMessage is to be used.
guusdk
added a commit
that referenced
this issue
Dec 8, 2020
When a previously archived message is being retrieved, the optional 'stanza' database value is eventually parsed as XMPP. This commit brings forward this process (to a place immediately after the data is obtained from the database), replacing the existing mechanism that did it just before the message was being routed to the intended recipient. The benefit of this is that the code that it is more fail-fast, and operations that follow the database retrieval can work with a proper stanza, instead of having to work with its String representation. This brings type-safety. Lastly, there's less ambiguity around where parsing occurs (and at what point the parsing can be expected to have been completed).
guusdk
added a commit
that referenced
this issue
Dec 8, 2020
The concept of 'direction' of an ArchivedMessage is, to some, counter-intuitive. The mechanism that determines the direction of a particular stanza should be centralized to reduce confusion.
guusdk
added a commit
that referenced
this issue
Dec 8, 2020
When processing an archived message in MAM context, using the 'with' attribute (that would otherwise go unused) to reflect the nickname of the sender of the message allows us to avoid unneeded stanza parsing.
guusdk
added a commit
that referenced
this issue
Dec 8, 2020
Code duplication (and thus complexity) is reduced by centralizing where an appropriate stanza ID is obtained.
guusdk
pushed a commit
that referenced
this issue
Dec 8, 2020
The implementation looks for a stanza-id and falls back to a database ID. The XEP-0313 says a client shouldn't rely on the stanza-id as the UID of a message in the archive, but OF is trending towards making that reliable. In the meantime, the result ID is still the database ID. Without this change, searches for the database ID is searched as freetext within the stanza. As a short number in amongst many GUIDs, false positives are more likely than not. This change adds to the defense against false positives and ensures that a search for a stanza-id is more thoroughly checked to be the one we were looking for.
guusdk
added a commit
to guusdk/openfire-monitoring-plugin
that referenced
this issue
Dec 11, 2020
guusdk
added a commit
to guusdk/openfire-monitoring-plugin
that referenced
this issue
Dec 14, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This project was created as a combination of two separate projects. The merge resulted in a lot of code that is not actually used by the implementation.
This code adds significant overhead in project maintenance, and should be removed.
The text was updated successfully, but these errors were encountered: