Google Talk

[Nathan Walp]

Sean Egan wrote:
> Richard has added Google Talk as a protocol option, and it doesn't
> look like anyone has removed it yet :)
> 
> At what point do we draw the line on special casing it? If we are now
> offering Google Talk specifically to people who don't realize it uses
> XMPP, and aren't likely to care, how closely should we try to map to
> Google Talk?
> 
> Specifically, XMPP defines five presence states: available, away,
> extended away, do not distrub, and chatty. Pidgin allows you to set
> all of them yourself. XMPP does not offer the concept of 'idle,'
> although I think iChat has introduced one.
> 
> These presence states are vaguely defined; clients are pretty much
> left to decide what to do with them.
> 
> Google Talk uses 'away' (defined as "The entity or resource is
> temporarily away") as a timeless idle state, like MSNs. We use 'away'
> as our "away" state, like AIM's. This is certainly a valid
> interpretation of the spec, but differs from what we do.
> 
> Google Talk allows you to set only two states: available and busy
> (XMPP's do-not-disturb). A Google Talk user, unaware of XMPP, might be
> confused when the available statuses are no longer 'available' and
> 'busy,' but 'available,' 'away', 'do not disturb', 'extended away,'
> and 'chatty."
> 
> The user might be similarly confused that it doesn't go 'idle' despite
> having his settings set to allow that and that he doesn't see his idle
> buddies as idle, but as away.
> 
> We can tell what buddies are using the Google Talk client at runtime.
> Would it be reasonable to show buddies using that client as 'idle,' as
> that's what 'away' means for those clients?
> 
> Additionally, it should be possible to define an idle state that only
> gets set if you're connected to a Google Talk server. This would make
> Google Talk users go 'idle' as other Google Talk users would expect.
> 
> I don't think it's possible to tell, at runtime, what statuses a
> protocol supports, but if it were possible, would it make sense to
> match Google Talk's? Further, if it's not possible at runtime, would
> it be too much to add a new prpl to enable it?
> 
> Thoughts?

I can't decide on a good spot in this thread to reply, so I'll just 
reply to the original post...

I'm OK with adding a Google Talk "protocol" as I've now personally seen 
enough people get confused without it.  That is fine.

I'm NOT OK with bastardizing the protocol the way Google has.  If I were 
Sean, I'd be at work screaming at the top of my lungs to fix their usage 
of XMPP, rather than expending ANY energy discussing this here.

There will be an idle spec for XMPP that doesn't require polling.  I'm 
going to write it if no one beats me to it.  I had suggested it at least 
a year ago, and was told to wait for pubsub/pep to settle down first. 
That seemed reasonable.

If Google wants idle so badly, they should contribute (or start even) 
that effort, not bastardize presence states.  If 'away' were to mean 
idle, they would have used 4 different bytes in the XML, namely 'idle'.

If Google were an island of XMPP, I might be able to be talked into 
this, but they're part of the federation of XMPP servers (I think that's 
what they're calling it these days), and they need to be acting like 
responsible users of the protocol.

Jabber, from the beginning, had the idea of making simple clients and 
complex servers.  This focus has been remarkably well kept over the 
years.  I believe this ideal can be further simplified into "fix things 
in as few places as possible."  I can count on my hands the number of 
widely-deployed Jabber servers, and on 1 finger the number of clients 
spitting out this strange twist on the protocol.  I have not enough 
fingers or toes to count the number of clients out there that adhere to 
the spec.  So, why not fix this in 1 place instead of making up for it 
in 50?

My $2.00.

-Nathan