Thanks for the reply Philipp. In that case I didn't understand the purpose of the new ways of fetching the archive as proposed by Matthew in https://github.com/xsf/xeps/pull/922 namly "before-id", "after-id", and "ids". I assumed that they operate not on the archive id provided by MAM but on the origin-id (or other id) provided by the user.
If they operate on the archive id provided by MAM, I think we are still missing a simple way for the sender to sync the archive. The user sending the message, doesn't know the archive id of the just sent message unless it tries to read it from MAM. I can imagine a situation where a user sent many messages to someone else, there was no message back from the other user when the sender was online. The next time our sender connects and wants to sync MAM it has to either query it by timestamp or use last known archive id, which is from before the messages were sent. In other words, I think it'd be good if the sender could quickly learn what is the archive id for the message it just sent, or has the ability to query the archive based on origin-id. Best regards Michal Piotrowski Software Architect at https://www.erlang-solutions.com/ email: michal.piotrow...@erlang-solutions.com skype: twitter/github/medium: michalwski On Tue, 12 May 2020 at 18:05, Philipp Hörist <phil...@hoerist.com> wrote: > Hi, > > I think you misunderstand the XEP, MAM does not care about what IDs a user > adds, it certainly does not care about origin-id, or the message-id. > > The server itself generates a unique ID when receiving a message and this > ID is communicated via the stanza-id element for example in MUC Messages. > > Or if you fetch messages via MAM, in the result element id attribute. > > Regards > Philipp > > Am Di., 12. Mai 2020 um 17:44 Uhr schrieb Michal Piotrowski < > michal.piotrow...@erlang-solutions.com>: > >> One more question, probably more general. What would be the most desired >> server's behaviour when it observes that a user sent a message with a used >> UID? In my opinion, it be better to reject this new message with an >> existing UID, if so how to communicate that error back to the sender? >> >> Best regards >> Michal Piotrowski >> Software Architect at https://www.erlang-solutions.com/ >> email: michal.piotrow...@erlang-solutions.com >> skype: twitter/github/medium: michalwski >> >> >> >> On Mon, 11 May 2020 at 10:22, Michal Piotrowski < >> michal.piotrow...@erlang-solutions.com> wrote: >> >>> Hi Matthew, >>> >>> Thanks for making the changes. I'm really in favour of them. I see there >>> was no update to the PRs nor here on the mailing list. What needs to happen >>> in order to proceed with these? >>> >>> Alos, I have a comment (or rather question) regarding the new way of >>> querying the archive based on message UIDs. I assume that by UID, you mean >>> the origin-id as set by the client sending the message. If so, it didn't >>> find it clearly stated in your proposed changes nor in the current >>> version of MAM XEP. If not origin-id is meant here, I'd like to know what >>> UID means in this context. >>> >>> Best regards >>> Michal Piotrowski >>> Software Architect at https://www.erlang-solutions.com/ >>> email: michal.piotrow...@erlang-solutions.com >>> skype: twitter/github/medium: michalwski >>> >>> >>> >>> On Wed, 22 Apr 2020 at 13:17, Florian Schmaus <f...@geekplace.eu> wrote: >>> >>>> On 4/22/20 12:07 PM, Matthew Wild wrote: >>>> > On Tue, 21 Apr 2020 at 15:50, Florian Schmaus <f...@geekplace.eu >>>> > <mailto:f...@geekplace.eu>> wrote: >>>> > On 4/21/20 2:32 PM, Dave Cridland wrote:> On Mon, 20 Apr 2020 at >>>> 16:20, >>>> > > You're going to hate me, but one more thing... >>>> > > >>>> > > Current MAM says that servers SHOULD include a count. The >>>> problem with >>>> > > this is that it's extremely slow on any system with more than >>>> trivial >>>> > > retention periods, since this tends to degenerate into either a >>>> > COUNT(*) >>>> > > SQL query (table-scan-tastic) or a standalone counter (which >>>> then >>>> > drifts >>>> > > and is a contention point). >>>> > > >>>> > > The majority of client libraries appear to ignore the count >>>> values >>>> > > anyway, as far as I can tell, so can we relax this to a MAY? >>>> (XEP-0059 >>>> > > is MAY-but-only-if, which is arguably really a SHOULD anyway). >>>> > >>>> > I think such a relaxation would require a namespace bump. >>>> > >>>> > I'm not convinced. In any case, servers that already comply with the >>>> > SHOULD will probably continue to do so, new servers may be more likely >>>> > not to, but given that clients don't really use the (unreliable) info >>>> > today then I don't think we lose anything in practice. >>>> >>>> I could follow that argumentation in this case. It's probably just me, >>>> but I am very conservative when it comes to relaxations of keywords. >>>> >>>> - Florian >>>> >>>> _______________________________________________ >>>> Standards mailing list >>>> Info: https://mail.jabber.org/mailman/listinfo/standards >>>> Unsubscribe: standards-unsubscr...@xmpp.org >>>> _______________________________________________ >>>> >>> >> Code Sync & Erlang Solutions Conferences >> <https://www2.codesync.global/l/23452/2019-11-13/6sypwx> >> >> >> Code BEAM Lite ITA - Bologna: Rescheduled >> >> Code BEAM STO - Stockholm: Rescheduled >> >> ElixirConf EU - Warsaw: 7-8 October 2020 >> >> Code Mesh - London: 5-6 November 2020 >> >> >> Erlang Solutions cares about your data and privacy; please find all >> details about the basis for communicating with you and the way we process >> your data in our Privacy Policy >> <https://www.erlang-solutions.com/privacy-policy.html>. You can update >> your email preferences or opt-out from receiving Marketing emails here >> <https://www2.erlang-solutions.com/email-preference?epc_hash=JtO6C7Q2rJwCdZxBx3Ad8jI2D4TJum7XcUWcgfjZ8YY> >> . >> >> >> _______________________________________________ >> 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 > _______________________________________________ > -- Code Sync & Erlang Solutions Conferences <https://www2.codesync.global/l/23452/2019-11-13/6sypwx> * * Code BEAM Lite ITA - Bologna: Rescheduled Code BEAM STO - Stockholm: Rescheduled ElixirConf EU - Warsaw: 7-8 October 2020 Code Mesh - London: 5-6 November 2020 * * Erlang Solutions cares about your data and privacy; please find all details about the basis for communicating with you and the way we process your data in our Privacy Policy <https://www.erlang-solutions.com/privacy-policy.html>. You can update your email preferences or opt-out from receiving Marketing emails here <https://www2.erlang-solutions.com/email-preference?epc_hash=JtO6C7Q2rJwCdZxBx3Ad8jI2D4TJum7XcUWcgfjZ8YY>.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
