[Standards] XEP-0313: pending 0.7 update review

Michal Piotrowski michal.piotrowski at erlang-solutions.com
Tue May 12 15:43:30 UTC 2020


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.piotrowski at erlang-solutions.com
skype: twitter/github/medium: michalwski



On Mon, 11 May 2020 at 10:22, Michal Piotrowski <
michal.piotrowski at 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.piotrowski at erlang-solutions.com
> skype: twitter/github/medium: michalwski
>
>
>
> On Wed, 22 Apr 2020 at 13:17, Florian Schmaus <flo at geekplace.eu> wrote:
>
>> On 4/22/20 12:07 PM, Matthew Wild wrote:
>> > On Tue, 21 Apr 2020 at 15:50, Florian Schmaus <flo at geekplace.eu
>> > <mailto:flo at 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-unsubscribe at 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>.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200512/22b7027c/attachment.html>


More information about the Standards mailing list