Tomasz Sterna wrote:
> Well.. Privacy extensions support is required for XMPP
compliance and
> all the major players do implement these.
>
> Psi has it, Gajim has it, tkabber has it, kf has it
Coming from a background of IM clients which are not
Jabber-specific
(things like Gaim, Kopete, etc) they all certainly have poor
or entirely
lacking support for these privacy extensions.
> It's not at all complex.
...
> The reason why blocking XEP appeared is that we cannot
agree on a
> common way of doing simple blocking and invisibility
over Privacy.
As for the complexity, we've looked at it in Telepathy and
decided we'd
prefer the simpler XEPs (or Google extensions, which we've
implemented
already) exactly because of the reasons you said - yes we
can provide a
function to block people or such, but in a simple
block/unblock API we
can't correctly represent/edit more complex privacy lists
which have
been set, so our implementation would interoperate poorly
with clients
which had set more complex privacy lists. We don't want to
harm
interoperability like this, so we havn't done it at the
moment.
Trying to deny that these extensions have a level of
complexity (or
perhaps over-generality) associated is perhaps a little
naive, because
otherwise it'd have surely been possible to define a
simplified profile
for blocking/invitility behaviour, like PEP simplifies the
adoption of
Pub/Sub in many clients. If all that you you want to do is
just block
someone or present a list of who is blocked, without having
to show
what's essentially an arbitrary ACL editor to the user (and
we don't
really want to do that in our standard APIs at the moment),
these
extensions *are* complex.
> jabberd14 has it, jabberd2 has it, ejabberd has it,
openfire has it,
> tigase has it.
Ah, for some reason I thought jabberd14 lacked it. My
mistake. Google
have certainly opted not to use it on their servers, and I
think that's
a pretty popular target for clients now.
> I personally think, that introducing alternatives for
the things we
> already have (like the second file-transfer protocol
that appeared)
> isn't good for the stability of the XMPP network.
Yes, file transfers aside, I think does need to be a good
reason to
consider introducing duplicated functionality into the XEPs.
Correcting
poor adoption or interoperability is one of those areas, I
think.
> I apology for the off-topic thread, but the unanswered
FUD is a
> successful FUD. It's EOT for me now.
I'm not intending to spread FUD, I was merely mistaken in
some areas. I
still maintain that it has an element of complexity to it
which makes
the simplified blocking and invisibility XEPs far more
appealing to us.
Regards,
Rob
_______________________________________________
Loudmouth mailing list
Loudmouth lists.imendio.com
h
ttp://lists.imendio.com/mailman/listinfo/loudmouth
|
