[Standards] Proposed XMPP Extension: MUC Auto-Join

[Rachel Blackman]

>> [Different Client Options for Joining a Room]
>
>> Since the room invites the user to the conference,
>> shouldn't this not be a client configuration/customization ?
>
> I don't think this is a room level thing - I think it's a client  
> thing.
> The room may be configured to allow all sorts of things, but it's  
> up to
> me which options I want.
>
> Other examples include a calendar function, "Auto-join this room
> Monday-Friday" or "Only join if the time is between 8AM and 5PM".
> (Similar to the way a recurring meeting setup works in Outlook).

In my opinion, anything that gets into that sort of complexity should  
be stored client-side entirely.  We don't need to get into the  
business of defining a full scripting language to attach to roster  
items.

It might be nice to be able to say 'join this room and bring it to  
the front under this nickname Monday-Friday between 8am and 5pm,  
unless I'm coming in from this IP in which case make it under this  
other nickname, but join it under this other nickname and minimize it  
upon join any time outside of those business hours' or whatever...  
but really, that's a client-specific thing, and I don't think we need  
to start trying to define a generic event-scripting system as part of  
XMPP itself... much less as part of the /roster/. :)

The advantage to the auto-invite-on-presence is that it will work  
with EVERYTHING.  Hands-down.  Anything which supports MUC invites  
will just /work/, right out of box, no worries about whether or not  
they add support for auto-join.  Given how long it can take us to  
roll out a protocol, the value of that should not be underestimated;  
an old copy of Exodus will support this method just as well as some  
new as-yet-unreleased supercool telepathic XMPP client down the road,  
or whatever.  Even without my suggestion of an added 'category' field  
in roster stuff, this solution is valuable specifically because of that.

The category field is mostly only useful so that you can recognize  
those items /right away/ (before getting entity caps, or in case the  
service is offline) to categorize them as gateways, or chatrooms, or  
whatever else.  Then I can make it so if there's a chatroom in my  
roster, it gets sorted into a 'chatrooms' group automatically, and  
clicking on it presents the join dialog (or just outright joins).  Or  
so that a chatroom automatically has a little 'chatroom' avatar.  Or  
so that it gets sorted into a 'favorite chatrooms' tab or whatever  
else my client-developer heart desires.

Storing preferred nickname, all that sort of stuff, sure, I'm fine  
with that.  But I don't know that it needs to be /right in the roster  
item/.  There's a huge difference between adding a single bit of data  
('category') which provides a very general but useful class of  
information, and overloading the roster to store large quantities of  
arbitrary data.

>> Does this need to go into roster ? Maybe in client's config  
>> settings ?
>
> I don't really see where else it would go. I certainly want it stored
> somewhere on the server, so that it works with all my clients.

Client-specific stuff stored server-side belongs in iq:private, or in  
whatever the successor to iq:private is, I think.  Rather than  
cramming it into the roster.

I mean, if people decide that it's fine for arbitrary client-specific  
data to go in the roster, I'll go right ahead and add support for  
cramming Trillian Astra's metacontact state data (priority/position  
of a contact within the overall cross-network metacontact), since  
that'd be useful to me.  But it doesn't seem to me under the current  
XMPP philosophy that such data belongs in the roster, since it /is/  
client-specific and probably not to useful to others.

Conversely, a category field is a very general bit of data, is  
generally useful (determine that a given contact is a gateway you're  
subscribed to, for instance, and since the category marks it as such,  
offer 'Unregister' or 'Disconnect from Gateway' options on it in the  
client UI) without the overhead of disco probes or requiring that all  
services support entity caps when in a roster, and is something all  
clients (at least, all clients that understand disco identity values)  
will understand already.

PLUS, it's easy to automate; add a JID, and the server does a quick  
disco probe for the identity field.  The category value comes back  
right then and there; clients are 'client' and chatrooms are  
'conference' and search services are 'directory' and so on.  So then  
as soon as you get the roster, you have all the information you need  
to know that 'users.jabber.org' in your roster is a directory search  
service, display a little Yellow Pages icon beside it, and make the  
double-click action pop open the appropriate search window, but that  
'jdev at conference.jabber.org' is a chatroom, show a little chatroom  
icon, and have double-click join you to it. :)

Anyway, there's my $0.02 on the whole thing, either way.

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