Google Talk

[Sean Egan]

On 5/23/07, Nathan Walp <nwalp at pidgin.im> wrote:
> 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.

I don't think that's fair. The XMPP spec is vague on the meanings of
these states. Given the highly-specific nature of RFCs in general, and
the XMPP RFCs in particular, I presume it's purposely vague, to allow
clients and severs to do whatever makes most sense to them.

In this case, "away" is defined simply as:

"The entity or resource is temporarily away."

That sounds, to me, 100% in sync with the Google clients' behavior of
setting this state on computer inactivity.In fact, one of the options
that's arisen in this thread is to have Pidgin match the Google Talk
presence implementation for all XMPP accounts. If you think this
behavior somehow violates the specification, let me know, and I'll see
what I can do. Then I'll remove "Auto-away" from Pidgin, as that also
allows for exactly the same, apparently bastardized, functionality.

This is the first complaint I've ever heard about how Google handles
presence, and I guarantee that if Google were doing something wrong,
I'd hear all about it.

You say I should be "screaming at the top of my lungs" for them to
"fix" this. To the contrary, when the issue has come up of creating an
explicit 'away' state and adding the notion of an idle time (more akin
to how AIM works), I've actually defended the current behavior (which
I was not part of creating, myself). To me, Google's system of
presence makes more sense than any other system I've seen (which is
essentially all of them).

Unless you can show otherwise, the behavior of the Google Talk clients
are in no way incompatible with the XMPP specification. Third party
clients are an important part of Google Talk, and so, naturally,
Google would never do something as braindead as having completely
incompatible states.

The issue I'm bringing up is whether Pidgin (and other libpurple
clients) should more closely match the behavior of the Google Talk
clients now that we're offering it as an option distinct from XMPP and
don't expect users to know anything about XMPP other than what they've
used in Gmail, for instance.

The entire question is about implementation details. There's no
bastardization going on. There's absolutely nothing wrong with keeping
Pidgin's current behavior. The question is now that we're offering
Google Talk as a protocol as and of itself, does it make sense to
match the behavior of the "official client" as we do for other
protocols.

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

That's fine. To be clear, though, the Google Talk clients don't
implement 'idle' in the sense of the "Last activity" XEP. It
essentially just offers Pidgin's "auto-away" functionality, always on,
and without a preference. If there were an idle-time XEP like the one
you're suggesting, Google Talk would certainly consider implementing
it; it happens to be orthogonal to this particular conversation,
though.

I hope that clears up some of the misunderstanding. If you have any
specific gripes, let me know.