On 2 December 2016 at 18:18, forenjunkie <forenjun...@chello.at> wrote:
> Ah now im understanding, basically the server should give you a list of > contacts to query for messages. > > i would see this as a simply addition to MAM. > Would you see it as a new parameter to MAM query? or rather a completely new kind of iq to MAM service? > The Archive already could know what messages you read, because of > chatmarkers. it would only need to hold the last read marker stanza id for > every contact in roster, and perform some SQL magic on query. > I can think of a situation where there is no roster (on XMPP server) but still there is archive and we want to get list of contacts with unread messages. I like Kevin's idea with the iq and list of unread messages in a result. Also I think it would be beneficial for clients to have not only id of the unread message but also the content. This could be optional, of course, but in some cases getting the unread message content would make UI update easier. The client doesn't have to query the archive if it only wants to display part of the unread message content on the UI. > > it would send you a list of contacts and afterwards you could start > querying the archive for messages of these contacts. > > > > Am 02.12.2016 um 17:14 schrieb Kevin Smith: > >> >> On 2 Dec 2016, at 16:03, forenjunkie <forenjun...@chello.at> 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 <forenjun...@chello.at> 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 <forenjun...@chello.at> 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: 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 >>>> _______________________________________________ >>>> >>> _______________________________________________ >>> 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 > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
