> On 18 Jan 2017, at 14:36, Michal Piotrowski > <michal.piotrow...@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.piotrow...@erlang-solutions.com > > On 18 January 2017 at 15:01, Evgeny Khramtsov <xramt...@gmail.com> wrote: > Wed, 18 Jan 2017 14:24:02 +0100 > Florian Schmaus <f...@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-unsubscr...@xmpp.org > _______________________________________________ > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
