[jdev] Re: discovering extensions without disco

[Robert McQueen]

Remko Troncon wrote:
> Different things come to mind:
> - Clients shouldn't really encourage non-standard behaviour, so i would
> personally not support this myself.

With my idealist hat on, yes, I agree - I hate the fact that I'm even
considering this. But for this particular project I'm working on, it's a
much better use of my time to spend 1 week adding Google Talk compatible
blocking than it is to spend 2 or 3 on some subset of jabber:iq:privacy
which isn't supported by a) the main server we're targetting, b) many
other clients, and c) probably only about half the servers around currently.

> - If you really want to support Google Talk, you can get away with a
> regexp match on the JID, and enable all these non-standard extensions.
> No other server is using these anyway. As long as GT doesn't change the
> allowable email addresses, you're safe.

I'm not too keen on this approach - in the UK for example, new GMail
customers are given addresses at googlemail.com because of successful
trademark action against "GMail". This could also change during the
lifetime of our product.

> - Since blocking is a task not often done, you can do it failure-driven:
> try blocking using iq:privacy (which is rather complicated right now,
> see below) if you think the server supports it, and then try this way if
> it fails. Pretty ugly still, but there is no way to cleanly support
> non-standard things on a server that does not advertise its extensions.

In my client, I don't want to present a server-side "Block List" to the
user unless I know that I can actually block. If I've disco'd and found
iq:privacy, and implement it, I can offer this, but I'm not sure what to
do on Google. Falling back to the google:roster stuff is not great
because I don't think it will really fail if it's not available.
Non-Google servers will either strip off the gr: stuff, or will happily
store it for me and return it in future roster queries, but in both
cases I will not get a failure and it will not actually block anybody on
the server either.

> This said, apart from GT not advertizing its extension in disco, i don't
> blame them for not supporting iq:privacy. It's very hard to use this
> protocol directly client-side for tasks as blocking or invisibility. A
> simple profile of this protocol should be made that blocks, unblocks and
> makes you invisible with one simple iq. I heard stpeter has this
> somewhere on his TODO.

Yeah, I don't blame them either... I'd agree that using iq:privacy looks
a little overcomplex for these common actions, and given that Google
already enforces "no messages unless you have a subscription" on the
server, the privacy interface is pretty gratuitous unless you're
blocking people on your roster, which is exactly what this extension does.

> cheers,
> Remko

Regards,
Rob