Mark Rejhon skrev 2011-08-19 00:02:
Also, I point out that your paragraph "section 10.2 is sufficient"
appears to contradict the next paragraph, "I do not think that is
needed..." because section 10.2 implies that it is needed.
I did not realize that you described a case with increasing latency
The GPRS networks where I have seen high latencies typically suffer from
"buffer bloat". As a result, instead of dropping packets in the event of
congestion, they just fill up the (overly large) buffers, demonstrating
larger and larger queuing delays until finally the buffers are full, and
(often
> In situations of connections normally averaging
> 1000ms or less, spiking to 3000ms, it is usually the safest and lesser
> evil (less screen-to-screen latency) to lengthen the transmission
> interval, in order to reduce screen-to-screen lag by reducing the
> number of bytes that "piles up" in mas
2011/8/18 Gunnar Hellström :
> To me it seems that section 10.2 is sufficient, and your discussion is just
> intended to clarify that, and give the mail list an example of one possible
> algorithm.
>
> Though, if I understand the algorithm right ,GPRS with 3 second round-trip
> would cause a transm
Mark Rejhon skrev 2011-08-18 16:29:
One possible simpler congestion-recovery algorithm that complies with
section 10.2 of XEP-0301 is simply using the average latency of the
last several message delivery receipts (XEP-0184) to automatically set
the interval, if it's longer than the default 1000ms
On Thursday, August 18, 2011 05:10:58 AM Goffi wrote:
> - the ability to get missed items between the last time a contact was
> disconnected and the time it reconnect
I have a protocol flow for reliable pubsub that I've not yet publicized, but
essentially the idea is to include Result Set Managem
It's my understanding of the XEP process that we standardise ways of
doing something so that many clients and servers can interoperate.
And for machine to machine services this is easy: machines do as we say
and interoperate as we say. It's a predictable environment.
Social is not easy and neithe
On Tue Aug 16 16:12:34 2011, Peter Saint-Andre wrote:
On 8/16/11 3:35 AM, Dave Cridland wrote:
> On Mon Aug 15 22:57:59 2011, Peter Saint-Andre wrote:
>> > 2) We also need to consider that many clients only handle one
status
>> > code.
>>
>> Which one do they handle?
>>
>>
> I mean they will o
Am 18.08.2011 15:43, schrieb Peter Saint-Andre:
I've completed a round of revisions to XEP-0045 (Multi-User Chat) in an
effort to incorporate developer feedback I've received since the last
version 3 years ago. The XMPP Council would like to vote on these
revisions before the end of September or
Version 0.2 of XEP-0296 (Best Practices for Resource Locking) has been released.
Abstract: This document specifies best practices to be followed by Jabber/XMPP
clients about when to lock into, and unlock away from, resources.
Changelog: Expanded intro with a short problem description; moved chat
Version 0.1 of XEP-0304 (Whitespace Keepalive Negotiation) has been released.
Abstract: This specification defines a method for negotiating how to send
keepalives in XMPP.
Changelog: Initial published version. (psa)
Diff: N/A
URL: http://xmpp.org/extensions/xep-0304.html
Le Jeudi 18 Août 2011 20:40:05, Sergey Dobrov a écrit :
>
> It's a bad idea to append the number to the namespace since it reserved
> for different revisions of XEP and not for your purpose. Again, I think
> that this should be solved by some privacy lists extension since your
> decision again res
> can be detected and trigger retransmission (see section 4.6.4 of
> XEP-0301) in an advanced implementation of XEP-0301.
That said, to prevent scaring programmers:
I should stress that minimal implementation of XEP-0301 (following
ONLY the 'REQUIRED'), is actually really simple. In my experience
> Mark Rejhon skrev 2011-08-18 05:33:
>>
>> XEP-0301 has section 10.2
>> that suggests you can dynamically lengthen the transmission interval
>> in order to survive extreme conditions like those you described. (i.e.
>> 2,000 or 3,000ms). Please note that this is no longer really
>> "REAL-time te
I've completed a round of revisions to XEP-0045 (Multi-User Chat) in an
effort to incorporate developer feedback I've received since the last
version 3 years ago. The XMPP Council would like to vote on these
revisions before the end of September or possibly early October, so it
would be great i
On 08/18/2011 08:09 PM, Goffi wrote:
> Le Jeudi 18 Août 2011 19:29:21, Sergey Dobrov a écrit :
>>> first, here are my main needs for microblogging:
>>>
>>> - the possibility to have several nodes with different access models,
>>> and for a user to subscribe to them automatically
>>
>> Could you giv
Le Jeudi 18 Août 2011 19:29:21, Sergey Dobrov a écrit :
> > first, here are my main needs for microblogging:
> >
> > - the possibility to have several nodes with different access models,
> > and for a user to subscribe to them automatically
>
> Could you give some example usecases for that? Since
On 08/18/2011 07:10 PM, Goffi wrote:
> G'day everybody,
>
> as it is my first post on @standard, I just quickly present myself: I'm the
> developper of "Salut à Toi", a multi-frontend XMPP client (you can have a
> presentation here ==>
> http://www.goffi.org/post/2011/06/05/Salut-%C3%A0-Toi%3A-
G'day everybody,
as it is my first post on @standard, I just quickly present myself: I'm the
developper of "Salut à Toi", a multi-frontend XMPP client (you can have a
presentation here ==> http://www.goffi.org/post/2011/06/05/Salut-%C3%A0-Toi%3A-
a-multi-frontends-XMPP-client ). My client use mi
I would also point out Tobias' request for clarification about the
DST.ADDR computation:
http://mail.jabber.org/pipermail/jingle/2011-August/001705.html
20 matches
Mail list logo
