XSF Discussion - 2023-04-17

Does xmpp mam support aborting a query? I can't seem to find anything relevant in the xep

kurisu: you get paginated results, and each page is "atomic" in that regard, but you can stop fetching additional pages

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.

a query is a IQ

and we have no way to abort a IQ

XEP-0326 has cancel commands for longer queries, esp. database readouts

https://xmpp.org/extensions/xep-0326.html ✏

(It also contains asynchronous reporting of long transactions and readouts)

Current: https://gitlab.com/IEEE-SA/XMPPI/IoT/-/blob/master/Concentrator.md ✏

search for “Query”

XMPP newsletter arrived in my mailbox as unrendered HTML. :/

Yes, commteam is aware afaik

yup

The entire setup is so fragmented and annoying...

Email? I agree :)

everything

Newsletter over XMPP when? 🙂

I'm actually just fine with RSS/Atom

Isn't there already a node on Movim? 😛

Interesting suggestion, maybe we should create a read only channel. but still, all that should be automated once merged. It's lots of wasted time

Ahh, see the good people are joining Mastodon! "ItS tHe PlAtforM noT the peOplE tHaT aRe ShIt..."

https://jabbers.one:5281/file_share/HPNnkQS7HLCj6sk_qObYNT1Z/b320a002-573f-49a6-94f5-ea336bed718c.png

#socialproblems

vanitasvitae, there is yeah, via atom2pubsub

> Isn't there already a node on Movim? 😛 https://mov.im/?node/pubsub.movim.eu/XMPP ↺

"You just have to implement a XEP"

you just have to immanentize the eschaton

Why does xmpp use the time format of 2010-08-07T00:00:00Z and not just unix time? Does it offer any advantages?

One advantage is that I can't read unixtime

Please hand in your geek badge Daniel.

kurisu: one disadvantage of unixtime is that it cannot represent leap seconds

or timezones

true, though use of these is discouraged in xmpp time anyway because privacy

plus sorting unix time requires parsing the integer

huh?

I am not sure if leap seconds are a valid argument

(for this discussion)

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.

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

April 32 1969

Zash, sorting two unix timestamps that are provided as string requires those to be parsed to integer first, no?

flow, why?

general numeric sorting algorithms exist

10 > 100?

presumably just ascii sort with some stuff to deal with different lengths yeah

ok you could fill in leading zeros probably

Trung, it's March 1143 of 2020, what's your point?

flow: > I am not sure if leap seconds are a valid argument > > (for this discussion) me neither :D

or September 10821 of 1993

Lunar calendar since Prosõdy is written in Lua

Epoch = https://slashdot.org/story/99/01/04/1621211/open-real-time-messaging-system

> 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

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

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)

or let me ask a counter question: why would you use unix time?

Because that's a common standard, there are tools to work with it for every language ever

Built in tools

I expect that also to be the case for ISO 8601

for example, coreutils' date has the -I switch

or milliseconds

Also: XML has a simple type for date & time (or date, etc.), something JSON doesn’t

Makes type-checking and interoperability easier

also makes validation of datatype possible (XML schema), in a standardized manner

+ transforms (XSLT)

agreed, but I don't understand the "or milliseconds" remark

unix time is number of seconds since Unix epoch

integer number of seconds

hmm that's a very strict definition of unix time

nothing says it can't have fractions of seconds

in fact, providing unix time in nanoseconds is common, e.g. in filesystems

> integer number of seconds What's an integer :) ↺

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.

you can of course make it floating point, or 64-bit, or…

but the point of a standard is not to go outside of the standard as soon as you start using it…

Standards!?!

yes, standard (including here "defacto standards" as Unix time, in JSON-based web APIs)

the xs:DateTime provides a more flexible standard for date-time timestamps in XML

I recently saw an awesome bug where the report was the UI was showing an incorrect integer

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

tl;dr computers suck

interesting, the XMPP IRI spec relies on stringprep

https://www.rfc-editor.org/rfc/rfc5122.html#section-2.2

means if we have a precis JID which is not a valid stringprep JID, we are in theory unable to build a IRI from this