[Standards] XEP-0313: pending 0.7 update review

Matthew Wild mwild1 at gmail.com
Wed Apr 22 10:07:12 UTC 2020


On Tue, 21 Apr 2020 at 15:50, Florian Schmaus <flo at geekplace.eu> wrote:

> On 4/21/20 2:32 PM, Dave Cridland wrote:> On Mon, 20 Apr 2020 at 16:20,
> Matthew Wild <mwild1 at gmail.com
> > <mailto:mwild1 at gmail.com>> wrote:
> >
> >     On Fri, 3 Apr 2020 at 21:51, Matthew Wild <mwild1 at gmail.com
> >     <mailto:mwild1 at gmail.com>> 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.
>

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.

Alternatively, we could add a flag in the query request to omit the
> <count/>.
>

I think that's not going to help - clients will not actively add it even if
they aren't interested. They ought to opt-in, if anything.


> Also given that <count/> is specified to potentially be approximate,
> implementations could just return 0 or 1 as count.
>

Indeed. It is already vague enough that I'm not even sure if we need to
relax it. But also relaxing it isn't a problem if that's what we think best
reflects reality.

Regards,
Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200422/ed65048f/attachment.html>


More information about the Standards mailing list