[Standards] Proposed XMPP Extension: MUC Auto-Join

[Rachel Blackman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> * 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.
>
> Can't you get this info via caps?

No.  Well, yes, but not in all cases.  As I mentioned before, caps is  
(unsurprisingly) unavailable when the entity is offline.

Among other things, this means a conference room might show as an  
offline user.  I see, say, 'jdev at conference.jabber.org' as just 'Dev'  
in my roster, I mistake it for 'Deb', and click there to send an  
offline message.  After all, I don't have the context necessary to  
show that it is a conference room offline due to service maintenance  
rather than a user, so as far as the client can tell, it can go right  
ahead and send an offline message to the bare JID, right?

Having category='conference' in the roster item means I avoid that  
case of confusion and indeterminacy.  Entity caps is great since it  
can record /additional/ data (is it password protected?  Does it  
support some nifty new MUC feature, like whiteboarding?  Etc.) which  
is only useful when the room is available, but I think the basic fact  
of determining that it /is/ a conference room is useful even when the  
room itself is unavailable.

>> * 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.
>
> Right, you get that with a mutual subscription. The 'to' gives you  
> entity capabilities, but nothing says you must make the  
> subscription bidirectional.

True.

I suppose you could display the conference room's return subscription  
as a 'do you want to auto-join?' -- there'd need to be a way to  
toggle that down the road (revoking subscription is easy enough, but  
you'd need a method to convince the conference room to re-request it  
if you decided you did want auto-join).  So I stand by my opinion  
that this needs a bit more thought.

> Oh and BTW nothing says that a conference room could not have an  
> avatar, a vCard, and everything else.

But nothing requires them to do so, either. :)

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFGYI7HvcwcncUz5OERAqlBAKDAXVkeYbPOWoZ6Hb8qHlTL2tN6LwCgp0Do
VmW5Udod6UD/uojWi5vVIrY=
=9A0P
-----END PGP SIGNATURE-----