[Standards] Proposed XMPP Extension: Bind 2.0

Kevin Smith kevin.smith at isode.com
Thu Jan 19 10:59:46 UTC 2017


> On 18 Jan 2017, at 14:36, Michal Piotrowski <michal.piotrowski at erlang-solutions.com> wrote:
> 
> I have another question regarding pipelining. From what I understand the very first connection to the server should be "normal" like - client sends packet, waits for the response(s) and proceeds. The next time all the mentioned things in the spec can be pipelined. What makes me wonder are server responses like stream features. Should server still send them? In my opinion they are redundant in this case as the client is probably not interested and already knows what features will be used.

I think they’re still interesting, as if there are more features available than before, the client could choose to use them on next connection.

/K

> 
> 
> Best regards
> Michal Piotrowski
> michal.piotrowski at erlang-solutions.com
> 
> On 18 January 2017 at 15:01, Evgeny Khramtsov <xramtsov at gmail.com> wrote:
> Wed, 18 Jan 2017 14:24:02 +0100
> Florian Schmaus <flo at geekplace.eu> wrote:
> 
> > Bind2 already tries to solve race conditions an XMPP client encounters
> > when creating a new session by atomically querying the users archive
> > for the ID of the latest stanza, binding the resource *and*
> > activating the stream of live stanzas right after the retrieved ID. I
> > believe you don't not a database with atomic operations to implement
> > that protocol step atomically server-side (by just locking the
> > archive and stanza stream of the user while that action is performed).
> 
> Ok, let's say you need to read some different tables (possibly in
> different databases, for example SQL and Redis). In order to do this
> atomically, you need to read one table, cache the results somewhere,
> then read the next table and cache the result and so on. So you need
> to maintain additional cache. And what if you need writes (enabling
> carbons requires writes I believe)? You need to discard all your writes
> if some of the table fails (simulating rollback). Is it's worth the
> effort?
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
> 
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________



More information about the Standards mailing list