Hi. First of all I want to mention how impressed/appreciative I am of the level of documentation within the code … at least for the MUC code which is all I have looked at. The class hierarchy and general design also seems great.
Within some internal usage scenarios, it is important for full history to be supported within persistent MUC rooms. Currently there is some history supported, but it only persists as long as there are users in the room … ie when the last user exits a room, Messenger (I think) must release the MUCRoomImpl instance associated for the room, which causes the memory-based history for the room to also be released. If the room is activated again …say because a user enters it, and new MUCRoomImpl is properly instantiated along with its MUCRoomHistory/MUCHistoryStrategy, but all previous history is long.
This is a known issue in Messenger, and has been posted as a bug and something to be addressed in a future release. The bug stated that history needs to be preserved in a database table in order to persist.
My main reason for posting this query is whether the current MUCConversationLog table, could be used as a persistent history. Of course, this table is only written to if the room was configured to ‘‘log’’, but otherwise it looked to me like it had the kind of info needed to persist history.
I modified a few classes (2.0.1) such that when a MUCRoomImpl is instantiated and populated from the database (via the MUCPersistenceManager), the MUCConversation log records for the room are also read in and fed to the MUCRoomHistory object. This seemed to work … of course I’'m new to Jabbber/IM and there are probably a lot of nuances that I have not captured for the history.
But I wanted to ask whether what I did has serious drawbacks, while I wait for persistent history to be supported?