[Standards] Proposed XMPP Extension: MUC Auto-Join

[Peter Saint-Andre]

Chris Mullins wrote:
> This is something we've talked about a number of time, and I'm still a
> bit torn on it.
> 
> 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. 
> 
> 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? 

/me whispers "entity capabilities"...

> There are two solutions I like a bit more, both of which are more work:

Why do you like them if they are more work? Job security? ;-)

> 1 - A "Startup" section in private storage (or a Startup PubSub node),
> that contains XMPP URI's that are acted upon when the client starts up.
> This could be very generic, and be extended to allow anything that RFC
> 4622 allows. It would be widely supported across clients, and is very
> flexible. 

Got any other use cases in mind? The phrases "very generic" and "would 
be widely supported across clients" don't seem harmonious to me.

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

Not needed if you have entity capabilities.

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070601/5fb1c0c7/smime-0001.bin