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
