On 08/13/2014 10:26 PM, Peter Saint-Andre wrote:
On 6/2/14, 10:48 AM, XMPP Extensions Editor wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Recipient Server Side Notifications Filtering
Abstract: This specification defines a modern efficient way to deliver
On 6/2/14, 10:48 AM, XMPP Extensions Editor wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Recipient Server Side Notifications Filtering
Abstract: This specification defines a modern efficient way to deliver PubSub
notifications.
URL:
The proposal has been updated getting rid of XEP-33 inside.
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
Abstract: This specification defines a modern efficient
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
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
Guys, could you please be more specific on what's wrong with XEP-33
because I don't really understand your concerns.
I don't think that it will be better to use my own protocol to put the
subscribers' JIDs into the event, right? So what are the options?
Thanks.
On 06/18/2014 04:21 PM, Kevin
On Jun 2, 2014, at 9:48 AM, XMPP Extensions Editor edi...@xmpp.org wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Recipient Server Side Notifications Filtering
Abstract: This specification defines a modern efficient way to deliver PubSub
notifications.
On Wed, Jun 18, 2014 at 9:20 AM, Lance Stout lancest...@gmail.com wrote:
On Jun 2, 2014, at 9:48 AM, XMPP Extensions Editor edi...@xmpp.org wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Recipient Server Side Notifications Filtering
Abstract: This
Hello Philipp, thanks for your feedback.
On 06/17/2014 03:02 PM, Philipp Hancke wrote:
Am 02.06.2014 18:48, schrieb XMPP Extensions Editor:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Recipient Server Side Notifications Filtering
Abstract: This specification
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Recipient Server Side Notifications Filtering
Abstract: This specification defines a modern efficient way to deliver PubSub
notifications.
URL: http://xmpp.org/extensions/inbox/rsf.html
The XMPP Council will decide in
17 matches
Mail list logo
