[Standards] XEP-0313: pending 0.7 update review

Michal Piotrowski michal.piotrowski at erlang-solutions.com
Tue May 12 16:44:37 UTC 2020


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



On Tue, 12 May 2020 at 18:05, Philipp Hörist <philipp at 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.piotrowski at 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.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>
>> .
>>
>>
>> _______________________________________________
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: Standards-unsubscribe at xmpp.org
>> _______________________________________________
>>
> _______________________________________________
> 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/2222a8a5/attachment.html>


More information about the Standards mailing list