XSF Discussion - 2023-04-17

  1. kurisu

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

  2. Ge0rG

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

  3. 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.

  4. lovetox

    a query is a IQ

  5. lovetox

    and we have no way to abort a IQ

  6. Peter Waher

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

  7. Peter Waher


  8. Peter Waher


  9. Peter Waher

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

  10. Peter Waher

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

  11. Peter Waher

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

  12. Peter Waher

    search for “Query”

  13. Guus

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

  14. Seve

    Yes, commteam is aware afaik

  15. wurstsalat


  16. emus

    The entire setup is so fragmented and annoying...

  17. moparisthebest

    Email? I agree :)

  18. emus


  19. Zash

    Newsletter over XMPP when? 🙂

  20. Zash

    I'm actually just fine with RSS/Atom

  21. vanitasvitae

    Isn't there already a node on Movim? 😛

  22. emus

    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

  23. emus

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

  24. emus


  25. mjk


  26. pep.

    vanitasvitae, there is yeah, via atom2pubsub

  27. edhelas

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

  28. edhelas

    "You just have to implement a XEP"

  29. Ellenor Malik

    you just have to immanentize the eschaton

  30. kurisu

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

  31. Daniel

    One advantage is that I can't read unixtime

  32. Guus

    Please hand in your geek badge Daniel.

  33. jonas’

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

  34. Zash

    or timezones

  35. jonas’

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

  36. flow

    plus sorting unix time requires parsing the integer

  37. Zash


  38. flow

    I am not sure if leap seconds are a valid argument

  39. flow

    (for this discussion)

  40. 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.

  41. 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

  42. Trung

    April 32 1969

  43. flow

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

  44. Zash

    flow, why?

  45. Zash

    general numeric sorting algorithms exist

  46. flow

    10 > 100?

  47. Zash

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

  48. flow

    ok you could fill in leading zeros probably

  49. Zash

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

  50. jonas’

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

  51. Zash

    or September 10821 of 1993

  52. Trung

    Lunar calendar since Prosõdy is written in Lua

  53. Zash

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

  54. kurisu

    > 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

  55. 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

  56. 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)

  57. flow

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

  58. kurisu

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

  59. kurisu

    Built in tools

  60. flow

    I expect that also to be the case for ISO 8601

  61. flow

    for example, coreutils' date has the -I switch

  62. Peter Waher

    or milliseconds

  63. Peter Waher

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

  64. Peter Waher

    Makes type-checking and interoperability easier

  65. Peter Waher

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

  66. Peter Waher

    + transforms (XSLT)

  67. flow

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

  68. Peter Waher

    unix time is number of seconds since Unix epoch

  69. Peter Waher

    integer number of seconds

  70. flow

    hmm that's a very strict definition of unix time

  71. flow

    nothing says it can't have fractions of seconds

  72. flow

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

  73. moparisthebest

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

  74. 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.

  75. Peter Waher

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

  76. Peter Waher

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

  77. Zash


  78. Peter Waher

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

  79. Peter Waher

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

  80. moparisthebest

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

  81. 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

  82. moparisthebest

    tl;dr computers suck

  83. lovetox

    interesting, the XMPP IRI spec relies on stringprep

  84. lovetox


  85. lovetox

    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