XSF Discussion - 2021-01-09

was xmpp:user:password@domain.example valid or not?

xmpp://user:password@domain.example should be, I don't think xmpp: is, no

thanks

For some value of "valid" that may include "deprecated for a decade"... 😕

Without replacement, since passing credentials around like that is not that great.

🤷️

Yes, better embed them in JSON instead ;)

Still supported by URI/URL parsers tho.. so I'd lean towards the sorta-standardized over made up JSON formats.

Re https://xmpp.org/extensions/xep-0313.html#query-limit-id Those two queries should give the same results if they had 'after-id' in RSM instead?

hm no the second would not end at the before id

Wouldn't that be subject to page sizes in both cases?

only because a page is finished

does not mean you get a complete=true iq

not sure what you are after, of course you can get the same messages with rsm, and then simply abort once you reach that stanza-id

but that is a bit weird given that this is a query protocol

do you make open ended SQL queries and abort once you think your done?

no you query exactly what you need, start -> end

and thats what these filter options allow now

In this code, the RSM before/after was translated to SQL WHERE. after-id and before-id would too.

Or would it? That's the question.

`WHERE id > (rsm.after OR after-id) AND id < (rsm.before OR before-id)` or somesuch

there is no rsm before AND after

its either or

That's not the point

if i understand you correctly you try to translate something, that cant be translated

the second example in the xep is not doable with rsm in an efficient manner

you could get lucky with the page size ending exactly on that stanza-id, and then you could abort

but thats luck

form.before-id=09af3-cc343-b409f rsm.after=28482-98726-73623

yes thats equivalent

now i understand you

🙂

rsm after == form after-id

so it does not matter which of the two you set

of course this depends on the implementation on the server

if the server like prosody only querys exactly the page it servs, then its equivalent

if some server would maybe prepare the whole result set, then this is performance wise maybe not equivalent

One difference I can think of is how the rsm count field is calculated. I'm assuming that should be calculated/estimated while ignoring the RSM bits

hm but count is a rsm feature

would be weird to igore the other rsm fields

hm no the XEP says it has to show the ful result set

yes, without the mam filter fields you would have to calc the count on each rsm query again

hm no only in the case no filter option was given

i dont see how this changes something Zash

count should always depend on the mam filter fields

now there are more filter fields but thats it

if i do a mam query without filters, no start date, no end date, the typical sign on and catchup after stanza-id

then count should be the count of all messages in the database for that account

yes. count should reflect how many messages match the base mam query.