On 4/21/20 2:32 PM, Dave Cridland wrote:> On Mon, 20 Apr 2020 at 16:20, Matthew Wild <[email protected] > <mailto:[email protected]>> wrote: > > On Fri, 3 Apr 2020 at 21:51, Matthew Wild <[email protected] > <mailto:[email protected]>> wrote: > > Hi folks, > > XEP-0313 is a well-established protocol at this point, but > didn't yet make it to the next stage in the standards process. > Time to fix that! > > I have made a final round of updates to incorporate the various > feedback I have received from people who have implemented the > protocol over the past couple of years. > > > I have just updated the PR in response to feedback here and in the MUC. > > Changes: > > - Removed the separate iq for fetching a single message by id, > this is now done via the 'ids' field in the data form and supports > multiple ids > > - Reverted the additional <gone/> error (the RFC defines this to > mean something else, and the information signaled to the client was > of questionable value) > > - Added an iq to query information about the id and timestamps at > the start/end of the archive, which can provide clients with useful > information. > > - Clarified the intention of the rule surrounding use of the > user's bare JID in the 'with' query field. > > Thanks to everyone for the feedback and suggestions! > > > 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. Alternatively, we could add a flag in the query request to omit the <count/>. Also given that <count/> is specified to potentially be approximate, implementations could just return 0 or 1 as count. - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
