Отправки пользовательского отредактированное присутствия в XMPP MUC комнату

сервера является Openfire с пользовательским компонентом работает и Клиент IOSОтправки пользовательского отредактированное присутствия в XMPP MUC комнату

1> User1 authenticates and then creates room1 and then sends a 
presence to server_comp 

2> Server_comp invites User2 to join room1 on behalf of User1 

3> User2 accepts the invitation and joins the room. 

4> All the message stanza conversation continues well.

Я хочу уведомить Пользователь2 всякий раз, когда есть место скоординировать изменения на стороне клиента User1. Это я хочу сделать через строфу присутствия.

Теперь Пользователь1 отправляет строку присутствия без упоминания о наличии. (Доступно) в комнату смещается вместе с элементом местоположения.

Строка присутствия от User1 к номеру не получена в User2.

У меня есть этот делегат, но это никогда не ударяет. Какая польза от этого делегата?

-(void)xmppRoom:(XMPPRoom *)sender occupantDidUpdate:(XMPPJID *)occupantJID withPresence:(XMPPPresence *)presence { 
    NSLog(@"%@ updated status with presence %@",[occupantJID full], presence.debugDescription); 
}

Если я отправляю по умолчанию присутствие, как недоступный тип и т. Д., Он отлично работает. Я упомянул определенную книгу XMPP и другие онлайн-документы, но не смог найти никакой помощи.

Теперь мое понимание - это индивидуальное изменение (добавленные атрибуты местоположения к присутствию), которое просто игнорируется самой комнатой. MUC может игнорировать присутствие с другими непонятными элементами. Это мое понимание правильно?

У меня есть второй вопрос:

компонент

Сервер приглашает Пользователь2 присоединиться к User1 создал комнату. Как только пользователь2 присоединяется к комнате, через некоторое время, если какой-либо из user1/user2 покинул комнату, почему сервер_компьютер также получает недоступное присутствие, хотя сам comp не является частью комнаты? Это похоже на то, что server_comp приглашает User2 от имени пользователя1?

источник

2016-06-28 SaffronState

О первом: следует игнорировать, но в зависимости от реализации. Однако спецификации позволяют использовать запрограммированные пользовательские теги, но, вероятно, вам просто нужно будет управлять jabber: x: event и/или добавлять дополнительные события. Около 2: зависит главным образом от реализации и конфигурации Openfire. – MrPk

@MrPk. О первом: вы говорите, что я все же могу настроить сервер для принятия измененной строфы присутствия у пассажиров? Я не мог получить никаких ссылок. Не могли бы вы указать, если это возможно, ссылку? Примерно 2: Поскольку вы, возможно, знаете о плохой документации openfire, за исключением просмотра кода, другого выбора нет, не так ли? – SaffronState

Я добавлю ответ, даже не могу ответить точно – MrPk

Я знаю, что не могу ответить на ваши вопросы, но есть много вещей, о которых можно поговорить: я разработчик Java, и я тоже был iOS, но я не знаю xmpp для iOS.

В общем, не существует механизма для проверки любого XML в OPENFIRE, поэтому вы можете изменить любой XML, как хотите. Поскольку Openfire работает с библиотекой XML Pull Parser, это safe, чтобы добавить новые атрибуты как ПОСЛЕДНИЕ.

Так что, если сообщение это как

<message> 
<body attr1="value1" attr2="value2"> 
</body> 
</message>

добавить свой собственный тег таким образом:

<message> 
<body attr1="value1" attr2="value2" customattr="customvalue"> 
</body> 
</message>

потому что XMLPullParser работает с позиций атрибутов, так что если в Openfire код будет прямой доступ к позиции (xml[1]), вы не будете уничтожать какие-либо функции. О порядке тегов нет проблем, просто не обернуть оригинальный корневой тег, так как примеры оба работ:

<message> 
<body attr1="value1" attr2="value2"> 
<customtagname xmlns="saffron.state:customaction"/> 
</body> 
</message> 

<message> 
<customtagname xmlns="saffron.state:customaction"/> 
<body attr1="value1" attr2="value2"> 
</body> 
</message>

Однако XMPP спецификации действительно гибкий, как я знаю, так что есть какой-то механизм, чтобы добавить определяемом события и пользовательские теги более или менее в каждой Stanza (= Packet), которую клиент может перехватить (в Smack API с помощью StanzaListener/Filter).

Наиболее распространенные элементы трескотня: х: событие (spec)

<x xmlns="jabber:x:event"> 
    <offline/> 
    <delivered/> 
    <displayed/> 
    <composing/>

но есть механизм выдвижения элементов, которые, вероятно, это то, что вы ищете, чтобы добавить функциональность (смотрите здесь: specification)

Подробнее: присутствие проходит в основном через Roster, но я думаю, вы говорите о groupchats. В groupchats есть механизм для пользователя ping, который кажется прозрачным, служба конференции имеет параметр в минутах, чтобы ударить пользователя, который остается бездействующим (по умолчанию: 30, но есть также «никогда»). Openfire предлагает эту функциональность в своей веб-консоли (groupchats -> Настройки Groupchat -> выберите конференцию -> другие настройки).

В групповых чатах необязательно пинговать чат, но вы, как разработчик, можете это сделать.

источник

2016-06-29 08:28:55 MrPk

спасибо. Я понял строфу сообщения. Но будет ли разница в настраиваемой (расширенной) строфе присутствия, специфичной для комнаты MUC? Всякий раз, когда я отправляю пользовательское расширенное присутствие в muc, оно никогда не обрабатывается. Однако, если я отправляю простое по умолчанию присутствие, он отлично работает. Я попробую еще раз добавить пользовательский тег в конце элемента и обновить здесь результат. – SaffronState

Мне очень жаль это слышать, но я не могу помочь на стороне клиента, возможно, у iOS api есть какая-то проверка xml или вам понадобится пользовательский прослушиватель/фильтр / – MrPk

Отправки пользовательского отредактированное присутствия в XMPP MUC комнату

ответ

Смежные вопросы