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
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: http://xmpp.org/extension
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 efficie
Mon, 23 Jun 2014 15:23:40 +0200
Kim Alvefur 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 implement.
On 2014-06-23 15:03, Evgeny Khramtsov wrote:
> Mon, 23 Jun 2014 12:11:35 +0100
> Dave Cridland wrote:
>
>> On 23 June 2014 11:44, Evgeny Khramtsov wrote:
>>
>>> 1) servers hold too much state
>>>
>>
>> What state do you think they hold that they should not?
>
> CAPs cache for example.
Prosody
On 23 June 2014 14:03, Evgeny Khramtsov wrote:
> Mon, 23 Jun 2014 12:11:35 +0100
> Dave Cridland wrote:
>
> > On 23 June 2014 11:44, Evgeny Khramtsov wrote:
> >
> > > 1) servers hold too much state
> > >
> >
> > What state do you think they hold that they should not?
>
> CAPs cache for example.
Mon, 23 Jun 2014 12:11:35 +0100
Dave Cridland wrote:
> On 23 June 2014 11:44, Evgeny Khramtsov 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
> >
>
> By "too much data",
On 23 June 2014 11:44, Evgeny Khramtsov 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:01:21 +0200
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 rep
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
> intr
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 issue
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
>
>
Wed, 18 Jun 2014 10:21:36 +0100
Kevin Smith wrote:
> The recipient-side filtering seems OKish, but could lead to situations
> where the publishing servers blindly send out to all possible
> recipient JIDs and let the recipients deal with whether to send to the
> clients or not - clearly not OK.
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 Smit
On Wed, Jun 18, 2014 at 9:20 AM, Lance Stout wrote:
>
> On Jun 2, 2014, at 9: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 e
On Jun 2, 2014, at 9: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: h
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 specifi
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 defines a modern efficient way to deliver PubSub
notifications.
URL: http://xmpp.org/extensi
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 the
19 matches
Mail list logo