On Thu Dec 22 10:00:56 2011, Sergey Dobrov wrote:
Look, the main problem is to update clients because clients are more
widespread. Destination filtering will not break compatibility with
clients. But chains can broke it depends on implementation. But
even for
server software we can maintain backwards-compatibility by using
server
caps. The transition period can be used during it filtering on
sender
can be announced as deprecated.
No, that argument is not applicable in this case.
We're talking about adding generic functionality in order to make
microblogging more useful. The only existing clients doing
microblogging over XMPP are the Buddycloud ones, which are using
generic pubsub.
You're arguing that, for example, PEP should fail to work unless both
servers support your new protocol. Given that the majority of XMPP
users do not have a server capable of any form of PEP, I don't see
why you think that your new, broken, PEP will deploy any better.
> But in general terms, PEP is done and deployed; changing it at
all is
> hard, changing it as radically as you propose is essentially a
> non-starter. It seems to me that the PEP subset is simply not
sufficient
> for your needs; you need to use something more, whether that's
more
> XEP-0060 features, or some other, new, protocol. But trying to
change
> PEP because it doesn't fit your use-case is just not going to
work.
Ok, you are suggest me to invent my own protocol.
No, I'm not. I'm saying that you can't use only the PEP subset, and
you need something more. That something could be a number of things,
including an entirely new protocol in the worst case, but I suspect
you need a lot less - a handful of existing XEP-0060 features would
work sufficiently well, and a few mionor extensions would probably
help for efficiency.
P.S. It will be really interesting if there are some examples of PEP
usage in commercial usage.
Buddycloud used to use PEP, very effectively. The reason they stopped
wasn't that PEP didn't work for them, it was because they wanted to
support users on Google, which has no PEP support. But Google users
can (and often do) see other people's PEP information; they just
can't publish their own.
What you're arguing for is a system where Google users wouldn't have
any PEP capability, and instead would get unfiltered subscriptions
whether they wanted it or not - particularly horrible for mobile
users. I don't think Google is going to suddenly implement your
protocol, so I think you need to figure out some other way to make
things work.
I've tried to help, but given you've decided you can't do anything
except rewrite PEP to suit your particular use-case, I'll leave you
to figure out the rest.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
