On Wednesday 05 April 2006 18:24, Robert McQueen wrote:
> 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.

Well, that much is easy.  If a server doesn't support iq:privacy, then don't 
let the user modify block lists.  Forget about storing weird things in the 
roster, because that's never going to work on any other server, and Google 
Talk, despite all the hype, is just one server of many.

The Google guys are fairly responsive to complaints anyway -- it didn't take 
very long for other things to be fixed in the past once people started 
hounding them for it.  I'd say it would be a better use of time to petition 
Google to implement these things properly, than to implement them as sticky 
tape and then find out the tape falls off when it's fixed properly.

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

As far as keeping things simple, a site could always choose to implement a 
subset of privacy list functionality, could they not?

  e.g.: - maintain a fixed set of lists
        - allow the client to edit the list which contains the users to block
        - don't allow them to create new lists
        - don't allow them to destroy existing lists

You could even implement trivial invisibility support like that, and the 
amount of protocol you would actually need to support would be tiny.  Just 
return something like <feature-not-implemented/> or <not-allowed/> for each 
feature you don't want to let the user do.

TX

-- 
             Email: [EMAIL PROTECTED]
         Jabber ID: [EMAIL PROTECTED]
          Web site: http://trypticon.org/
   GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F  A62C B8C7 BC8B 037E EA73

Attachment: pgpz028Olu1OG.pgp
Description: PGP signature

Reply via email to