Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
XMPP Extensions Editor wrote:
Version 0.6 of XEP-0186 (Invisible Command) has been released.
Abstract: This document specifies an XMPP-compatible protocol for user
invisibility.
Changelog: Clarified that this specification is intended to supersede
XEP-0018 and XEP-0126; added several additional examples. (psa)
Diff:
http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0186.xml?r1=489&r2=1204
URL: http://www.xmpp.org/extensions/xep-0186.html
We have so many specs for invisibility (and similar) feature - privacy
lists, block lists, the various invisiblity specs.
So many? Let's not exaggerate. I see three (block lists do not provide
invisibility):
Deny presence-out can be simulated by blocking lists using
wildcards/lists - but you are right, that is not in the spec.
1. XEP-0018, i.e., <presence type='invisible'/> -- we know this is is
evil (at the least, it would not pass muster in the IETF).
2. XEP-0186, i.e., a small, focused command for toggling invisibility.
3. XEP-0016, i.e., privacy lists -- these can be used to provide
invisibility, but that seems like a heavy weapon for such a small feature.
I remember another spec which used iq - cant seem to find it though.
Isn't this spec, for example, just special casing presence-out:deny ?
"
<iq type='set' id='invisible'>
<query xmlns='jabber:iq:privacy'>
<list name='invisible-all'>
<item action='deny' order='1'>
<presence-out/>
</item>
</list>
</query>
</iq>
"
Yes it is. But then you need access to a server and client that support
privacy lists. And you need to fiddle with your privacy lists all the
time to add and subtract invisibility, which it seems to me introduces
the possibility of messing up the definitions (not to mention the
bandwidth usage). A small, focused command seems more useful to me.
In our client for example, there is a 'invisible to all' list which just
does the above - invisibility actually gets shown in the ui as though it
was a presence status.
For more complex and custom privacy lists, there is ui - but the simple
static stuff does not require any editing of lists.
(Oh, that makes me realize: we could also do this via XEP-0050!)
Either we should have a proliferation of small specs which implement
subset's of functionality required, or have something like privacy list
which handles all cases (maybe something better designed if that is a
concern ?) - having both together means neither server, not client can
rely on support of these (unless they implement all).
MUC and presence are just subsets of pubsub, too, you know. :)
Really I don't have strong feelings about this. People were complaining
about privacy lists being so complex, so I wrote XEP-0186. If people
don't think we need it, that's fine with me, because personally I think
invisibility is a silly feature and I never use it. :)
We just end up with multiple ways of doing the same thing. So either we
fix what is wrong with privacy lists (now that it is not in the rfc), or
deprecate it altogether and come up with a good alternative (we are
seeing more adoption of privacy lists at server side iirc).
pubsub is complex too - but we do not necessarily come up with
alternatives to it (and yes, pep does not count :) it uses pubsub, not
replace it like this spec does).
- Mridul
Peter
