[Standards] Proposed XMPP Extension: MUC Auto-Join

[Rachel Blackman]

> On one hand, I really like having a Conference Room (which is just a
> JID) on my roster. It's integrated with what I want to do, the Roster
> GUI is already defined and present, and I'm used to interacting with
> people and starting a conversation by clicking on a user in the  
> roster.
> It's a very pragmatic solution, and fits quite well.
>
> On the other hand, a conference room is different, and having it on  
> the
> roster doesn't make sense. For example, looking at my roster I can't
> tell a conference room from a normal user. Maybe I threw it in a Group
> called "Conference Rooms", but that's pretty weak in terms of  
> metadata.

I think honestly we might want to consider:

* A 'category' in the roster items, such as category='conference';
   a blank category is assumed to be 'client'.  Categories would be  
taken
   from disco category types.  This would allow clients to sort  
chatrooms
   (or add a custom client-side avatar) in some manner appropriate  
for the
   UI.

* Some method to do a 'from' presence subscription with a chatroom.  I
   may not want auto-invites, but I may want presence.  This is a great
   thing because, let's say a conference server goes offline.  Boom, the
   conference rooms vanish from my roster, and I know they're  
unavailable.
   When they're online, I just click on one and boom, I join.

> The conference room doesn't have an Avatar associated with it, so it's
> going to look a bit funky in my roster (at least in the  
> implementations
> that I know of). The room also doesn't have a VCard associated with  
> it,
> so I can't really show a lot of data for the room, when treating it  
> as a
> Contact. When a user clicks on the roster item, the client typically
> starts sending messages - in the case of the conference room, how does
> the client know to instead start the conversation out by sending
> directed presence?

See above.  You can probe a room and get all the MUC info to display,  
use
a custom avatar for chatrooms, and change the context menu accordingly,
whatever. :)

> 2 - Adding metadata into the items on a roster - that way we can  
> include
> enough standard display hints to do fun things. This lets us store
> people on there, rooms, and anything else that is represented as a  
> JID.

See above.  I think 'category' is actually sufficient for this, as we  
already
have categories defined.  If it's a chatroom, you know you can obtain  
more
information by probing it for MUC info.  If it's a service, you know  
you can
obtain more by probing it for general disco info.  If it's a client  
(or has
no 'category' defined), you know you can... well, do whatever you do  
now. :)

-- 
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/