So guys, what are the exact concern around the XEP-0033 and what should
I use instead? I did not get your points.
On 06/02/2014 11:48 PM, XMPP Extensions Editor wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Recipient Server Side Notifications Filtering
Am 23.06.2014 09:41, schrieb Sergey Dobrov:
So guys, what are the exact concern around the XEP-0033
None of us has ever seen 0033 deliver on reducing the amount of s2s
traffic. Even the authors of 0033 agreed to this in the repeater
introduction.
Using 0033 unconditionally has trust
On 06/23/2014 05:01 PM, Philipp Hancke wrote:
Am 23.06.2014 09:41, schrieb Sergey Dobrov:
So guys, what are the exact concern around the XEP-0033
None of us has ever seen 0033 deliver on reducing the amount of s2s
traffic. Even the authors of 0033 agreed to this in the repeater
Mon, 23 Jun 2014 12:01:21 +0200
Philipp Hancke fi...@goodadvice.pages.de wrote:
Am 23.06.2014 09:41, schrieb Sergey Dobrov:
So guys, what are the exact concern around the XEP-0033
None of us has ever seen 0033 deliver on reducing the amount of s2s
traffic. Even the authors of 0033 agreed
On 23 June 2014 11:44, Evgeny Khramtsov xramt...@gmail.com wrote:
1) servers hold too much state
What state do you think they hold that they should not?
2) clients receive too much data
By too much data, do you mean irrelevant data or redundant data, or
something else?
Mon, 23 Jun 2014 12:11:35 +0100
Dave Cridland d...@cridland.net wrote:
On 23 June 2014 11:44, Evgeny Khramtsov xramt...@gmail.com wrote:
1) servers hold too much state
What state do you think they hold that they should not?
CAPs cache for example.
2) clients receive too much data
On 23 June 2014 14:03, Evgeny Khramtsov xramt...@gmail.com wrote:
Mon, 23 Jun 2014 12:11:35 +0100
Dave Cridland d...@cridland.net wrote:
On 23 June 2014 11:44, Evgeny Khramtsov xramt...@gmail.com wrote:
1) servers hold too much state
What state do you think they hold that they
On 2014-06-23 15:03, Evgeny Khramtsov wrote:
Mon, 23 Jun 2014 12:11:35 +0100
Dave Cridland d...@cridland.net wrote:
On 23 June 2014 11:44, Evgeny Khramtsov xramt...@gmail.com wrote:
1) servers hold too much state
What state do you think they hold that they should not?
CAPs cache for
2) We route shitload of presences to a client. On and on this goes.
clients generated a shitload of autoaway presence.
darth is busy now (Away as a result of being idle more than 5 min)
and ten minutes later
darth is away now (Away as a result of being idle more than 15 min)
Seriously, what is
Mon, 23 Jun 2014 15:23:40 +0200
Kim Alvefur z...@zash.se wrote:
When does this happen? Other clients should check with disco#info and
caps if the client supports things before sending them.
This happens when a server doesn't cache caps.
Presence de-duplication would be very interesting to
Version 0.1 of XEP-0349 (Rayo Clustering) has been released.
Abstract: This specification describes an extension to the Rayo protocol to
support clustering of Rayo servers and their presentation as a unified service.
Changelog: Initial published version approved by the XMPP Council.
Since use of XEP-0033 for more efficient S2S has reared its ugly head once
more, I thought I'd try tackling this problem from a different direction.
We've rejected a number of designs (around 6 or 7) over the years aimed at
solving this general problem - sending multiple stanzas to a set of jids
On 23 June 2014 14:51, Philipp Hancke fi...@goodadvice.pages.de wrote:
2) We route shitload of presences to a client. On and on this goes.
clients generated a shitload of autoaway presence.
darth is busy now (Away as a result of being idle more than 5 min)
and ten minutes later
darth is
On 2014-06-23 20:25, Ivan Vučica wrote:
I've taken a few moments and looked more closely at XEP-0313. A few
comments follow, primarily about section 5.1 Simple configuration.
This section can be interpreted as if settings for all jids have to be
retransmitted, even if only one change has
Thanks for the answers!
A few more thoughts.
I'd be happier if a standard didn't *assume* a low number of user initiated
actions, even if that is the reasonable and most probable use case here.
Client should be dumb and say 'hey, please add this jid to always' and
server should be smart enough
Hi,
I've read about XEP-0319: Last User Interaction in Presence and wonder
where's the difference to XEP-0256: Last Activity in Presence?
For me both cover the same use cases.
When should a client use one over the other? Ok… for now XEP-0319 is still
experimental, so a client would prefer
On Jun 23, 2014, at 12:53 PM, Christian Schudt christian.sch...@gmx.de wrote:
Hi,
I've read about XEP-0319: Last User Interaction in Presence and wonder
where's the difference to XEP-0256: Last Activity in Presence?
For me both cover the same use cases.
Right. XEP-0319 is intended to
[...]
The converse of these - bandwidth efficient, secure/private, RTT
efficient - would form our requirements.
makes sense.
I'd note a couple of changes to the server landscape might affect our
thoughts here.
a) As annoying as it is to me, compression seems related to a number of
security
On 23 June 2014 21:15, Philipp Hancke fi...@goodadvice.pages.de wrote:
[...]
The converse of these - bandwidth efficient, secure/private, RTT
efficient - would form our requirements.
makes sense.
I'd note a couple of changes to the server landscape might affect our
thoughts here.
19 matches
Mail list logo
