-
Guus
When filtering a MAM archive by time, what is the desired/expected behavior if the specified time is some instant in the future?
-
Guus
Returning an error might cause issues with systems that have drifting clocks. Returning a result might cause the client to think that all messages up to that point in time have been synced.
-
jonas’
do the latter and tell clients not to do that
-
jonas’
for sync, IDs are the only safe way
-
jonas’
for ephemeral display, times are OK
-
Guus
Educating users. What could possibly go wrong...
-
jonas’
s/users/developers/!
-
Guus
Openfire currently delays the response until that time has reached. Works for drifts, I think, but we had an ever running request just now...
-
jonas’
that sounds like an excellent way to DoS openfire
-
Guus
There are easier ways.
-
Holger
Heh, creative solution! 🙂
-
flow
shouldn't mam queries with an 'end' value that is potentially affected by time drift simply not contain an 'end' value?
-
flow
or is their intention something else than "give me all messages (starting from X) up to now"?
-
Guus
I don't know. From what I notice in the logs, at least someone is putting in an 'end' value for reasons beyond me 🙂
-
Ge0rG
The only excuse to use timestamps in MAM is when the client wasn't active for an eternity, and you only want "the last 14 days of history"
-
jonas’
Ge0rG, but then not for "end"
-
Ge0rG
jonas’: yes
-
Ge0rG
But then again, there is no way to ensure there is a no-overlap no-holes connection setup.
-
Ge0rG
So developers might be inclined to use timestamps to reduce the overlap or hole
-
Kev
I think that's outright wrong. There are a number of good reasons to search an archive using timestamps.
-
jonas’
(that’s what I meant by "ephemeral display" fwiw)
-
Kev
And I can even see why a naive implementation might end up requesting dates in the future
-
Kev
Let's say you've got a renderer that shows a day's history at a time, you might end up requesting 'the end of today' instead of adding logic to check if it's today and removing the end from it.
-
jonas’
hence my suggestion to simply truncate at $now and return immediately
-
Kev
Indeed, that seems to be correct behaviour to me.
-
jonas’
you could also return an IQ type='error' <error type='continue'/> if you’re fancy and want to break everyone✎ -
jonas’
you could also return an IQ type='error' <error type='continue'/> if you’re fancy and want to break everything ✏
-
Zash
We need to use error type=continue for something!
-
flow
Would it be sensible to add a note to xep313 to not use 'end' == now, but instead omit 'end', to avoid issues with holes where end < now?
-
jonas’
if you want to avoid holes, don’t use timestamps
-
lovetox
flow does the xep not mention what a missing end attribute does already?
-
flow
lovetox, probably, but that appearantly does not prevent developers from setting end=now. Not that I believe a note would change much, but at least it is documented
-
flow
I think I personally would favor erroring queries with a timestamp in the future, so that developers are forced to re-think their design. But I know that my "fail hard and fast (per default)" - whatever that actually means is subjective - is not undisputed✎ -
flow
I think I personally would favor erroring queries with a timestamp in the future, so that developers are forced to re-think their design. But I know that my "fail hard and fast (per default)" ideology - whatever that actually means is subjective - is not undisputed ✏
-
Zash
Pretty sure Prosody just turns it into a query equivalent to `WHERE "when" BETWEEN ($start AND $end)`
-
flow
Kev gave a nice example why erroring on such queries may be not a good idea, but I think I would favor that tiny little bit of extra client logic, over the (granted, probably small) possiblity that clients end up with holes
-
Zash
What if you cheat and set the 'complete' flag to false?
-
lovetox
thats a bad idea
-
lovetox
that would trigger another query
-
lovetox
so endless loop
-
lovetox
we had that with biboumi a year ago
-
flow
how do I suggest items for the xmpp newsletter? writing here? if so → https://www.netways.de/blog/2020/08/28/zurueck-in-die-zukunft-icinga2-benachrichtigungen-mit-xmpp/
-
moparisthebest
I think you ping emus ^
-
pep.
You can PR against https://github.com/xsf/xmpp.org/pull/756
-
emus
flow: yes, what pep. says. If you write a short text for it, what would be really helpful, it is just fine to comment there or in the CommTeam MUC as well.
-
jonas’
dwd, next doors✎ -
jonas’
dwd, next door? ✏
-
jonas’
(council@)