ejabberd - Comments for "JEP-0045 - implementing contact query"

Thanks

Yermo — Fri, 18 Nov 2005 09:58:23 +0000

Thanks.

In ejabberd you can forbid

teo — Thu, 17 Nov 2005 19:37:32 +0000

In ejabberd you can forbid room creation by users. Just look at mod_muc options in the ejabberd guide.

But indeed you're right. Room creation and joining shouldn't be done the same way.

I don't have knowledge

mfoss — Thu, 17 Nov 2005 19:11:06 +0000

I don't have knowledge enought to answer about advanced usages of MUC protocol :P

If nobody else gives you an answer on this forum, ask the JDEV mailing list at jabber.org, since it's more of a general Jabber question, and there you will get the attention of JEP45 authors, client and server developers...

good point.

Yermo — Thu, 17 Nov 2005 08:27:39 +0000

That's a very good point. I was thinking too narrowly and had not considered the multi-server case.

We're currently trying to work around the ad-hoc conference creation problem in the jabber protocols. Creation and Joining are the same thing. So if you're trying to join a conference but mistype the name you'll create one. For novice users (and our target audience is very novice) it can cause alot of confusion.

Even bookmarks don't do what we need. If you have a bookmark and the conference no longer exists, a new conference with be created.

We would like to separate creation and joining into separate actions and we would like to create a separate view of conferences, for a given server, that a user belongs to. Unlike bookmarks, this list would automatically be updated as conferences are destroyed.

So we need to be able to query the server for the list of conferences, on a given server, that a contact is a member of.

As I read JEP45, you can send a query to a conference for all the rooms currently defined but not for membership.

Am I missing something?

Who should answer, the server or the client?

mfoss — Wed, 16 Nov 2005 22:46:43 +0000

I would like to implement support for querying a contact to get a list of conferences that contact is a member of per JEP-0045

You refer to section 6.2: Discovering Client Support for MUC. That section describes how a client can ask a contact two things: if he supports MUC, and what chatrooms has he joined. When I read it, I understand that a client asks another client, it's not the serve the one responsible to collect information and answer.

Consider this situation:

Elements: client1, client2, server1, server2, mucservice1, mucservice2, chatroom1, chatroom2.
client1 and client2 are logged on server1.
mucservice1 is hosted on server1, and has chatroom1
mucservice2 is hosted on server2, and has chatroom2
client2 joins chatroom1 and chatroom2
client1 wants to know which chatrooms is client2 joined to.

Who can answer the question (is able to answer the question correctly)?

server1
server2
mucservice1
mucservice2
client2

I think that only client2 knows which chatrooms he is joined. His server could spy the packets and collect information, but reading JEP-45 I don't think that's the intention at all.

What do you think?