Two problem with openfire's muc component

I found two problems with current openfire muc component.

  1. My Tkabber send “history” for limit strings/chars from room’s history.

Openfire count this limits with room subject.

If room have big history I have empty subject every time. With big limits it works fine.

I think openfire should force sending room’s subject message.

  1. I gets two “bye-bye” (unavailable presence) every time I leave room.

PS. Please excuse my Engrish Thanks.

  1. Are you sure this is not a Tkabber specific issue? With Exodus i can leave 50 and more messages and it will pull all them and still i can see the subject. You can try limiting the number of history messages shown upon joining the room (Admin Console > Group Chat > selected conference service > History Settings. Maybe this can be as a workaround for Tkabber.

  2. Have filed the ticket - OF-48

That is not Tkabber issue.

With history maxstanzas=‘20’

Online

I haven’t subject in answer.

Without history tag:

Online

I have:

Community Chat

With history maxchars=‘10000’:

Online

I have:
Community Chat

With history maxchars=‘100’

Online

I haven’t subject in answer.

Sorry. I cant reproduce this or i just cant uderstand how exactly to do this.

Mozes poprobovat objasnit na russkom (tolko latinicei, kirillica so vremenem prevratica v ??? zdes). Ili pridetca podozdat poka kto poumnei razberetca v etom

We do not have access to the control panel ourselves. What is described here is a problem that is occurring in a public muc.

When a clients joins a muc, it can specify a history limit indicating how many messages from the history of the muc it wants to get. The problem is that Openfire includes the topic change in this history. So if someone changed the topic and after that 20 messages appeared, then the topic will not show up anymore for clients requesting only 20 messages when joining the muc.

To reproduce this, change the muc topic, fill the muc history with loads of messages. Then join the muc with Tkabber. The topic will not show then. Join the same muc with Psi and the topic will show up.

I see now. Though i cant find anything about how should be subject sending handled in xmpp standard http://xmpp.org/extensions/xep-0045.html

En: Openfire should send Subject message anyway, without any history limits. I think

Subject message is not real message. It is special message.

Ru: Openfire dolgen by otpravlat’ soobschenie s temoi v lubom sluchae.

Eto ved’ ne obychnoe, a slugebnoe soobschenie. Na moi vkus takie veschi vpolne logichnye i da, mogut byt’ propuscheny v xep-ah.

V obschem muc komponent dolgen vysalat’ ego v lubom sluchae, esli tema zdana konechno

Ok. I have filed this as a bug and let the devs decide what this really is - http://www.igniterealtime.org/issues/browse/OF-55

Today, another bug in Openfire’s MUC showed up again. The topic (in Psi) was set to something ancient again. It’s not clear when this happens, maybe when the room becomes empty or when Openfire is restarted. But sometimes the topic has suddenly been changed to something very old when I join the room. I think Openfire’s MUC should take some extra care when handling the conference topic.

Well, MUC code has a lot more bugs in Openfire and even not all of them filed in the bug tracker. Someone should recheck all the MUC code, i think.

I have created a patch which I believe resolves both of these issues:

http://www.igniterealtime.org/community/thread/39822

I just commented on the OF-55 for your first issue:

In my opinion this issue is invalid. The clients should querying for room information to get the room’s subject. Only subject modifications are sent as normal messages to inform all occupants about the change and this should be included in the rooms history (see XEP-0045). So this message is only to inform users that the subject has changed, in my opinion it isn’t intended for setting up the client’s subject when someone joins a room. So I think the subject change is sent correctly from Openfire and if any client depends on a subject change message to setup the subject it should be an issue of this specific client.

So I think it’s a tkjabber specific issue. Next, I will have a look on your second concern.

I agree with Guenther on that. My first thought was that this is not logical to get room’s subject from the history. I just wasnt able to find those links in XEP. Closing the issue and removing the Fix version, so it won’t block 3.6.5 release, if it would be reopened by any chance.

  1. Tkabber, not Tkjabber

  2. http://xmpp.org/extensions/xep-0045.html#subject-mod

“In addition, the room SHOULD include the last subject change in the discussion history sent when a new occupant joins the room.”

Yes, it should, and Openfire is including it in history. What Guenther was saying and how i understand the XEP: client shouldnt rely on history while querying room’s subject. It should do a disco query for a subject (whether it was changed or not) and then pull history (limited or not).

Hi,

  1. Tkabber, not Tkjabber
    sorry for the mistake.
  1. http://xmpp.org/extensions/xep-0045.html#subject-mod
    “In addition, the room SHOULD include the last subject change in the discussion history sent when a new occupant joins the room.”

Yes, after a second look on the spec and the discussion I think it isn’t 100% clear and I have doubts that I have correctly interpreted it. Thats why I wrote a mail to the XFS MUC mailing list and maybe St Peter as the author will clarify this.

Peter Saint-Andre has clarified:

Our problem is, if a client requests a limited history how should this limit affect the last subject?
The room should always send you the subject. The subject is not part of this history, it is more like a defining part of the room (or at least the room’s current context).
Reopened OF-55.

Committed the attached patch which checks if the last subject change is included in the limited room history and adds them if necessary. This should be included in the next Openfire release. Feel free leave a comment if you see improvements for the patch.
addChangedSubject.patch.zip (1089 Bytes)

Awesome, that is a good addition since I had just noticed yesterday that I get the room subject twice if it is included in the limited history. Thanks!