[Standards] Proposed XMPP Extension: Bind 2.0

Kevin Smith kevin.smith at isode.com
Thu Jan 19 10:58:24 UTC 2017


On 19 Jan 2017, at 10:37, Michal Piotrowski <michal.piotrowski at erlang-solutions.com> wrote:
> Few more question, just to be on the same page:

Yes, thanks for spending the time thinking about it!

> >Work out which contacts have unread messages in the user's MAM archive, how many, and what the id of the last read message is
> 
> 1. I assume the ids are the same as in MAM and can be later used to query MAM. Am I right?

Yes, absolutely.

> 2. What exactly do we understand by "contact" here? An item in user's roster or maybe just a unique JID from the whole archive. I worked with systems where there were no roster (not in XMPP world) but still there was MAM. Also a contact doesn't have to be in user's roster to be able to chat with it and still the user may want to have information about unread messages for such a contact.

The other XEP is likely to say that a user can send an iq to the archive saying something like <archive-read xmlns… contact=‘alice at wonderland.lit’ id=‘1’/> and the archive would then remember that state. When generating the unread list on bind2, the archive would send it for any jid that has sent a message to the user since the last read id for that jid. Does that make sense? (How the server stores that internally is up to it, but I can think of a number of sensible options, depending on the storage of the archive).

/K

> 
> 
> Best regards
> Michal Piotrowski
> michal.piotrowski at erlang-solutions.com
> 
> On 18 January 2017 at 15: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.
> 
> 
> 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