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 _______________________________________________
