> On 2 Dec 2016, at 16:03, forenjunkie <[email protected]> wrote: > > Why would you querry the whole archive?
Because the question isn't "do I have unread messages for contact X?" It's "in what chats do I have unread messages and how many?" on login. I don't see a way to solve this using the building blocks we have without exhaustive querying of the archive. The case of fetching context when the user later opens a chat is the easy part. This is why I asked with a specific example, for which I don't think we currently have protocol. Can you show me what the protocol would look like for the case I mentioned earlier? /K > > if you open a chat with a contact you querry "Give me the last X messages for > contact A" > > And if you open the chat window with contact B you do the same for contact B. > > I never did write a implementation of MAM myself, but if im reading the XEP, > you can filter with various attributes, you dont have to step through EVERY > message. > >> Am 02.12.2016 um 16:57 schrieb Kevin Smith: >>> On 2 Dec 2016, at 15:49, forenjunkie <[email protected]> wrote: >>> Its not written down somewhere that its up to the client, but it makes no >>> sense to put a selflimiting hard rule on a archiving XEP like MAM and >>> exclude certain messages per XEP rule. >> >> >>> We have store hints, the most prominent servers respect these. And it would >>> make no sense to not respect it if a client explicitly wishes for a message >>> to be stored. >> Oh, it’d make lots of sense. Server admins can very reasonably want to >> choose how their archive is populated, rather than having remote clients do >> so. >> >>> So to make it more clear, if i want to save a message on a current prosody >>> or ejabbered MAM implemenation, i can do this as a client with a store hint. >> While that’s nice for you, Prosody and ejabberd are certainly not the whole >> world ;) >> >>> you dont have to querry the whole archive, you just querry until you get a >>> read marker, then you know everything that comes before that was already >>> read so i dont have to query it. >> This is untrue, though. If I have two contacts, it’s quite easy for me to >> have unread messages for contact A that are hundreds or thousands of >> messages older than my messages from contact B, all of which are read. If I >> merely read the archive backwards until I found a read marker, I wouldn’t >> find the unread messages for contact A. >> >> /K >> >>> >>>> Am 02.12.2016 um 16:34 schrieb Kevin Smith: >>>>> On 2 Dec 2016, at 15:26, forenjunkie <[email protected]> wrote: >>>>> in a single chat conversation, it makes no sense to query unread messages. >>>> I’m not sure that’s true at all, but putting that to the side for the >>>> minute... >>>> >>>>> you could just query the last 10 MAM Messages, if no readmarker comes >>>>> with it, query another 10. such a implementation of MAM would be very >>>>> weird to me, but you could do it and get only unread messages with it. So >>>>> this already works without problem with the MAM and 0333 XEP. >>>>> And in single chat its not possible to "miss" a message in between, which >>>>> you would want to query. >>>> I think you’re missing the details of what I asked - how do you achieve >>>> this where there are a sufficient number of messages that just keeping >>>> querying until you have every message in your local archive isn’t viable? >>>> >>>>> And this is not a theory, XEP-0333 are stored by the server if the client >>>>> wishes that, and working implementations of MAM and 0333 together you can >>>>> witness for example in Conversations. >>>> It’s not up to the client whether 333 is stored by the server or not. >>>> >>>>> All i see in this proposal is adding complexity to the whole process in >>>>> introducing another thing the server has to support. >>>> Referring back to my previous question, can you provide an example of how >>>> to achieve this case with just 313 and 333 (in protocol)? >>>> >>>> /K >>>> _______________________________________________ >>>> Standards mailing list >>>> Info: https://mail.jabber.org/mailman/listinfo/standards >>>> Unsubscribe: [email protected] >>>> _______________________________________________ >>> _______________________________________________ >>> Standards mailing list >>> Info: https://mail.jabber.org/mailman/listinfo/standards >>> Unsubscribe: [email protected] >>> _______________________________________________ >> _______________________________________________ >> Standards mailing list >> Info: https://mail.jabber.org/mailman/listinfo/standards >> Unsubscribe: [email protected] >> _______________________________________________ > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
