Senden benutzerdefinierten bearbeitet Präsenz XMPP MUC Raum

Server ist mit Openfire benutzerdefinierte Komponente ausgeführt und Client ist iOSSenden benutzerdefinierten bearbeitet Präsenz XMPP MUC Raum

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.

Ich möchte User2 benachrichtigen, wenn es Ort, an User1 Clientseite koordinieren Veränderungen. Dies möchte ich durch Anwesenheitsstanze tun.

Nun sendet User1 die Anwesenheitsstanzzeile, ohne presence.type (verfügbar) für den Raum jid mit dem Standortelement zu erwähnen.

Die Anwesenheitsstanzzeile von User1 zu Raum wird bei User2 nicht empfangen.

Ich habe diesen Delegierten implementiert, aber das trifft nie. Was nutzt dieser Delegierte?

Wenn ich Standardpräsenz wie nicht verfügbaren Typ usw. senden, funktioniert es gut. Ich habe XMPP definitives Buch und andere Online-Dokumente genannt, konnte aber keine Hilfe finden.

Jetzt ist mein Verständnis die benutzerdefinierte bearbeitet (hinzugefügt Standortattribute an die Anwesenheit) Präsenz wird einfach durch den Raum selbst ignoriert. MUC ignoriert möglicherweise Präsenz mit anderen nicht verständlichen Elementen. Ist das mein Verständnis richtig?

Ich habe eine zweite Frage:

Die Serverkomponente User2 lädt Benutzer1 erstellt Raum zu betreten. Sobald user2 dem Raum beitritt, und nach einiger Zeit, wenn einer der Benutzer1/Benutzer2 den Raum verlassen hat, warum erhält der Server_Comp auch eine nicht verfügbare Präsenz, obwohl die Komposition selbst nicht Teil des Raumes ist? Ist es so, weil server_comp Benutzer2 im Auftrag von Benutzer1 einlädt?

Quelle

2016-06-28 SaffronState

Über die erste: sollte ignoriert werden, aber hängen von der Implementierung ab. Spezifikationen lassen sich jedoch für benutzerdefinierte Tags des Programmierers zur Verfügung stellen, aber wahrscheinlich müssen Sie nur jabber: x: event verwalten und/oder zusätzliche Ereignisse hinzufügen. Ungefähr 2: hängt hauptsächlich von Implementierung und Openfire-Konfiguration ab – MrPk

@MrPk Über erstens: sagst du, dass ich Server noch konfigurieren kann, um geänderte Anwesenheitsstrophe von den Insassen zu akzeptieren? Ich konnte keinen Hinweis bekommen. Könnten Sie bitte einen Hinweis geben, wenn möglich? Über 2: Wie Sie vielleicht von einer schlechten Dokumentation von Openfire wissen, gibt es keine andere Möglichkeit, als in Code zu schauen, oder? – SaffronState

Ich werde eine Antwort hinzufügen sogar ich kann nicht genau antworten – MrPk

Ich weiß, dass ich Ihre Fragen nicht vollständig beantworten kann, aber es gibt viele Dinge zu besprechen: Ich bin ein Java-Entwickler und ich war auch ein iOS, aber ich kenne XMPP für iOS nicht.

Im Allgemeinen gibt es keinen Mechanismus, um XML in OPENFIRE zu validieren, so dass Sie beliebige XML ändern können, wie Sie möchten. Da Openfire mit der XML Pull Parser-Bibliothek arbeitet, ist es sicher, neue Attribute als LAST ONES hinzuzufügen.

Also, wenn eine Nachricht ist es wie

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

Ihren eigenen Tag auf diese Weise hinzufügen:

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

weil XMLPullParser mit Positionen von Attributen arbeitet, also wenn in Openfire-Code wird es ein direkte sein Zugang zu einer Position (xml[1]) Sie werden keine Funktionalität zerstören. Über Tag bestellen gibt es kein Problem, nicht nur ursprünglichen Root-Tag wickeln, um Beispiele werden beide Werke:

<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>

jedoch XMPP Spezifikationen sind wirklich flexibel, wie ich weiß, so es einen Mechanismus gibt definiertem Ereignisse und benutzerdefinierte Tags hinzufügen mehr oder weniger in jeder Stanza (= Paket), die ein Client abfangen kann (in Smack API mit einem StanzaListener/Filter).

Die häufigsten Elemente sind Jabber: x: Veranstaltung (spec)

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

aber es gibt Verlängerungselement Mechanismus, es ist wahrscheinlich das, was Sie hinzufügen Funktionalität suchen (hier: specification)

Mehr: Präsenz passiert hauptsächlich durch Roster, aber ich denke du redest über Gruppen. In Gruppenchats gibt es einen Mechanismus zum Pingen von Benutzern, der transparent erscheint. Der Konferenzdienst hat einen param in Minuten, um einen Benutzer zu kicken, der im Leerlauf bleibt (Standard: 30, aber es gibt auch "nie"). Openfire bietet diese Funktionalität in seiner Webkonsole an (groupchats -> Groupchat-Einstellungen -> wählen Sie einen Konferenzdienst -> andere Einstellungen).

In Gruppenchats ist es nicht obligatorisch, den Chat zu pingen, aber Sie als Entwickler können es tun.

Quelle

2016-06-29 08:28:55 MrPk

danke. Ich habe die Nachrichtenzeilen verstanden. Aber gibt es einen Unterschied für benutzerdefinierte modifizierte (erweiterte) Präsenzzeilen, die spezifisch für MUC-Räume sind? Wann immer ich eine benutzerdefinierte erweiterte Präsenz an Muc sende, behandelt es nie. Wenn ich jedoch eine einfache Standardpräsenz sende, funktioniert es gut. Ich werde erneut versuchen, das benutzerdefinierte Tag am Ende des Elements einzufügen und hier das Ergebnis zu aktualisieren. – SaffronState

Tut mir leid, das zu hören, aber ich kann auf der Client-Seite nicht wirklich helfen, vielleicht hat iOS API eine Art XML-Validierung oder Sie benötigen einen benutzerdefinierten Listener/Filter/was auch immer – MrPk

Senden benutzerdefinierten bearbeitet Präsenz XMPP MUC Raum

Antwort

Verwandte Themen