Does xmpp mam support aborting a query? I can't seem to find anything relevant in the xep
Ge0rG
kurisu: you get paginated results, and each page is "atomic" in that regard, but you can stop fetching additional pages
marc0shas left
marc0shas joined
Rebeldhas left
Guus
kurisu: I don't think that there's an explicit: "stop executing the ongoing, minute-long database query" if that's what you're asking. Ideally, server implementations prevent those queries from being executed, by returning only a partial result that can be computed in a timely fashion. YMMV.
stphas joined
Andrzejhas left
Sevehas joined
neoxhas left
atomicwatchhas joined
atomicwatchhas left
Andrzejhas joined
atomicwatchhas joined
Andrzejhas left
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
projjalmhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
yushyinhas left
Menelhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
adiaholichas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
debaclehas joined
adiaholichas joined
atomicwatchhas joined
atomicwatchhas left
lovetox
a query is a IQ
lovetox
and we have no way to abort a IQ
atomicwatchhas joined
Menelhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
archas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
stphas left
florettahas joined
nicolahas joined
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
petrescatraianhas left
Ellenor Malikhas left
Ellenor Malikhas joined
Titihas left
nicolahas left
Sevehas left
Vaulorhas left
florettahas left
Vaulorhas joined
Sevehas joined
nicolahas joined
marc0shas left
marc0shas joined
debaclehas left
Stevehas joined
florettahas joined
Stevehas left
Stevehas joined
Stevehas left
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
nicolahas left
yushyinhas joined
SteveFhas joined
Stevehas joined
resolihas left
Titihas joined
marc0shas left
marc0shas joined
inkyhas joined
Yagizahas left
stphas joined
paulhas joined
govanifyhas left
Maranda[x]has left
KitKat::new()has left
Mjolnir Archonhas left
Marandahas left
Ingolf[m]has left
brunrobehas left
Rebeldhas joined
neshtaxmpphas left
neshtaxmpphas joined
neoxhas joined
florettahas left
govanifyhas joined
Andrzejhas joined
florettahas joined
Half-Shothas left
uhoreghas left
homebeachhas left
Matthewhas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
Ellenor Malikhas left
papatutuwawahas joined
Ellenor Malikhas joined
ralphmhas joined
Yagizahas joined
Yagizahas left
Yagizahas joined
adiaholichas left
Yagizahas left
Yagizahas joined
adiaholichas joined
stphas left
Maranda[x]has joined
KitKat::new()has joined
BASSGODhas left
no_1729has left
resolihas joined
Mikaelahas joined
BASSGODhas joined
marc0shas left
marc0shas joined
Andrzejhas left
resolihas left
Mikaelahas left
sonnyhas left
Mikaelahas joined
sonnyhas joined
debaclehas joined
Peter Waher
XEP-0326 has cancel commands for longer queries, esp. database readouts
> Isn't there already a node on Movim? 😛
https://mov.im/?node/pubsub.movim.eu/XMPP ↺
florettahas left
edhelas
"You just have to implement a XEP"
roothas left
roothas joined
florettahas joined
Ellenor Malik
you just have to immanentize the eschaton
wladmishas left
wladmishas joined
stpeterhas joined
edwinmhas joined
Titihas joined
BASSGODhas left
BASSGODhas joined
Andrzejhas left
jgarthas left
papatutuwawahas left
papatutuwawahas joined
adiaholichas left
adiaholichas joined
florettahas left
florettahas joined
sjmhas left
resolihas joined
marc0shas left
marc0shas joined
rumin-millerhas joined
rumin-millerhas left
snowhas left
nicolahas joined
guus.der.kinderenhas left
atomicwatchhas left
stphas joined
resolihas left
jcbrandhas left
jcbrandhas joined
gooyahas left
neshtaxmpphas left
neshtaxmpphas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
BASSGODhas left
marc0shas left
marc0shas joined
resolihas joined
brunrobehas joined
florettahas left
florettahas joined
gooyahas joined
resolihas left
neshtaxmpphas left
neshtaxmpphas joined
BASSGODhas joined
papatutuwawahas left
Andrzejhas joined
Ingolf[m]has joined
asterixhas left
asterixhas joined
Titihas left
Titihas joined
Titihas left
marc0shas left
marc0shas joined
neshtaxmpphas left
neshtaxmpphas joined
jgarthas joined
marc0shas left
marc0shas joined
neshtaxmpphas left
Stevehas left
kurisu
Why does xmpp use the time format of 2010-08-07T00:00:00Z and not just unix time? Does it offer any advantages?
nicomuchas joined
Stevehas joined
neshtaxmpphas joined
neoxhas left
Daniel
One advantage is that I can't read unixtime
Guus
Please hand in your geek badge Daniel.
neshtaxmpphas left
neshtaxmpphas joined
asterixhas left
asterixhas joined
jonas’
kurisu: one disadvantage of unixtime is that it cannot represent leap seconds
resolihas joined
jgarthas left
Marandahas joined
Zash
or timezones
nicomuchas left
jonas’
true, though use of these is discouraged in xmpp time anyway because privacy
flow
plus sorting unix time requires parsing the integer
Calvinhas left
nicomuchas joined
Zash
huh?
flow
I am not sure if leap seconds are a valid argument
flow
(for this discussion)
Zash
The advantage of the current format is that we're already using it and it's unlikely there's another _standard_ format that offers sufficient advantages to justify changing it.
flow
and I believe that use of timezones is not discouraged in xmpp time, but using your own timezone when emiting a timestmap will reveal your timezone, which is sometimes desired and sometimes not
Trung
April 32 1969
flow
Zash, sorting two unix timestamps that are provided as string requires those to be parsed to integer first, no?
Zash
flow, why?
Zash
general numeric sorting algorithms exist
flow
10 > 100?
Zash
presumably just ascii sort with some stuff to deal with different lengths yeah
flow
ok you could fill in leading zeros probably
Zash
Trung, it's March 1143 of 2020, what's your point?
jonas’
flow:
> I am not sure if leap seconds are a valid argument
>
> (for this discussion)
me neither :D
> The advantage of the current format is that we're already using it and it's unlikely there's another _standard_ format that offers sufficient advantages to justify changing it.
I'm just wondering why it was chosen over unix time to begin with
flow
kurisu, I think unix time is sensible if you store something in a uint32_t or uint64_t, but for a string based protocol ISO 8601 makes just more sense
flow
as daniel put it, you can't look at a unix time and tell which human date it represents, but ISO 8601 is human readable, and even what we germans where thought to use in formal letters (at least when I was in school)
florettahas left
atomicwatchhas joined
atomicwatchhas left
flow
or let me ask a counter question: why would you use unix time?
marc0shas left
marc0shas joined
kurisu
Because that's a common standard, there are tools to work with it for every language ever
kurisu
Built in tools
atomicwatchhas joined
atomicwatchhas left
flow
I expect that also to be the case for ISO 8601
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
flow
for example, coreutils' date has the -I switch
atomicwatchhas joined
atomicwatchhas left
marc0shas left
marc0shas joined
Peter Waher
or milliseconds
Peter Waher
Also: XML has a simple type for date & time (or date, etc.), something JSON doesn’t
atomicwatchhas joined
atomicwatchhas left
Peter Waher
Makes type-checking and interoperability easier
nicomuchas joined
Peter Waher
also makes validation of datatype possible (XML schema), in a standardized manner
Peter Waher
+ transforms (XSLT)
atomicwatchhas joined
atomicwatchhas left
flow
agreed, but I don't understand the "or milliseconds" remark
Peter Waher
unix time is number of seconds since Unix epoch
Peter Waher
integer number of seconds
flow
hmm that's a very strict definition of unix time
flow
nothing says it can't have fractions of seconds
flow
in fact, providing unix time in nanoseconds is common, e.g. in filesystems
moparisthebest
> integer number of seconds
What's an integer :) ↺
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
Peter Waher
If we’re talking about Unix time:
> The Unix time_t data type that represents a point in time is, on many platforms, a signed integer, traditionally of 32 bits (but see below), directly encoding the Unix time number as described in the preceding section. Being 32 bits means that it covers a range of about 136 years in total. The minimum representable date is Friday 1901-12-13, and the maximum representable date is Tuesday 2038-01-19. One second after 03:14:07 UTC 2038-01-19 this representation will overflow in what is known as the year 2038 problem.
nicomuchas left
Peter Waher
you can of course make it floating point, or 64-bit, or…
adiaholichas left
Peter Waher
but the point of a standard is not to go outside of the standard as soon as you start using it…
Zash
Standards!?!
Peter Waher
yes, standard (including here "defacto standards" as Unix time, in JSON-based web APIs)
Peter Waher
the xs:DateTime provides a more flexible standard for date-time timestamps in XML
papatutuwawahas joined
jgarthas joined
moparisthebest
I recently saw an awesome bug where the report was the UI was showing an incorrect integer
moparisthebest
Turns out, the backend API was returning proper json, with "fieldName": 64578877 (number made up) but the UI was calling json parse and then json stringify on it before displaying, and it was too many bits for JavaScript Number, so it just silently made the number different
moparisthebest
tl;dr computers suck
florettahas joined
jgarthas left
marc0shas left
jgarthas joined
marc0shas joined
adiaholichas joined
Martinhas left
Martinhas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
Andrzejhas left
marc0shas left
marc0shas joined
Martinhas left
Martinhas joined
Martinhas left
Martinhas joined
neshtaxmpphas left
neshtaxmpphas joined
nicomuchas joined
Yagizahas left
yushyinhas left
yushyinhas joined
stpeterhas joined
intosihas left
intosihas joined
jcbrandhas left
jcbrandhas joined
jgarthas left
belovehas left
belovehas joined
resolihas joined
belovehas left
guus.der.kinderenhas joined
BASSGODhas left
govanifyhas left
belovehas joined
govanifyhas joined
debaclehas left
guus.der.kinderenhas left
debaclehas joined
eevvoorhas left
archas left
archas joined
atomicwatchhas left
Calvinhas joined
atomicwatchhas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
Maranda[x]has left
Maxencehas left
stpeterhas left
Maxencehas joined
Half-Shothas left
Matthewhas left
homebeachhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
paulhas left
BASSGODhas joined
nicomuchas left
stpeterhas joined
stpeterhas left
snowhas joined
lovetox
interesting, the XMPP IRI spec relies on stringprep