-
thndrbvr
Bridges and bots. i.e. streamlabs type stuff. discord <-> twitch. (Ew but so useful. Greatly adds to the experience)
-
Guus
Is there any concern that would prevent xep-0431 from progressing?
-
Guus
I believe it primarily standardizes a field name for functionality that is already implemented in various servers (Openfire, EJabberd and M-Link, from my old notes).
-
Guus
I got in another "oh we can't use it because the XEP says you shouldn't do this in production" argument that I'd like to avoid in the future. :)
-
MattJ
I don't like it as-is, but it shouldn't be hard to fix
-
MattJ
And I say this every time it comes up
-
Zash
Write down what and why, post it to the list?
-
MattJ
We need to standardize two fields: one that guarantees no interpretation (the input is always treated as literal text) and another that allows implementation-defined syntax
-
MattJ
If we only standardize one, it should be the former, but this XEP currently says it is the lattet✎ -
MattJ
If we only standardize one, it should be the former, but this XEP currently says it is the latter ✏
-
MattJ
Which makes it painful for interop, useful only for closed deployments
-
MattJ
I'd be interested to know what current implementations are doing
-
MattJ
If they're all doing simple search then we should just adjust the semantics of the current field, if not then we should define a second one
-
Guus
Openfire currently takes the value, and will process it as a Lucene index query.
-
Guus
eg: "experiance" (SIC) yields 2 results from 11 million archived messages, while "experiance~" yields 500, which is a little bit more than the literal search for "experience"
-
MattJ
Right, exactly what I feared 🙂
-
MattJ
I will attempt a PR if you attempt to prevent me forgetting
-
Guus
Sure, thanks.
-
Guus
feasible timeline after which pokes are in order?
-
Guus
(hours, days, weeks?)
-
MattJ
Poke me early next week
-
Guus
ack
-
arc
So.. meeting today?
-
MattJ
arc, what do you think? :)
-
MattJ
Guus, is the Openfire search code public? Can you share a link to it if so?
-
arc
I think that once again I came to the scheduled meeting to find no one here
-
moparisthebest
arc: https://i.imgflip.com/6id83h.jpg
-
arc
That's a pretty huge compliments to compare me to sanders
-
Guus
> Guus, is the Openfire search code public? Can you share a link to it if so? MattJ: Yes, it is part of the Monitoring plugin for Openfire (where the MAM implementation lives). It's in this repo: https://github.com/igniterealtime/openfire-monitoring-plugin
-
Guus
I can give more details when I am near a pc again. I am on mobile now.
-
MattJ
Thanks
-
MattJ
Guus, https://matthewwild.co.uk/uploads/xeps/xep-0431.html + https://github.com/xsf/xeps/compare/master...mwild1:xep-0431-v0.3.0?expand=1
-
MattJ
This closes all my personal open issues with full-text search in MAM
-
guus.der.kinderen
MattJ: wow, that's quite an addition. I wonder if we're edging towards overkill, but I don't have any objections to that.
-
guus.der.kinderen
Is having a registry of search syntax types going to be practical, when alternatives start to pop up for the same syntax type, but with a different version identifier, or somesuch? We can certainly maintain a registry - but should we?
-
MattJ
I'm open to not, but I think it's helpful if most people are going to be using the same engines (there aren't an infinite number of them)
-
MattJ
It just gives clients even more of a chance to offer some sane UI around this feature, but I expect most won't anyway
-
Guus
¯\_(ツ)_/¯
- Zash - an appreciator of XEP-0122 - wonders if XEP-0122 could be used to signal such stuff
-
MattJ
Zash: which stuff exactly?
-
Zash
The _stuff_ !!
-
MattJ
I didn't think that language/syntax fitted as validation, so I made custom elements
-
Zash
Here, probably inventing a datatype per engine.
-
Zash
Language does indeed not quite fit into that without further fiddlery.
-
MattJ
guus.der.kinderen: if you think the proposed additions might be overkill... now that you've seen them, what would you cut out?
-
MattJ
Only the syntax?
-
MattJ
(+registry)
-
Zash
Hm, `xml:lang`
-
Guus
MattJ: even though your update is a lot more feature rich, I wonder if the added complexity hinders adoption more than it adds any real world value through implementation. Like you said: most probably won't implement the details anyway. With that in mind, I would be fine with the previous version of the XEP.
-
Guus
I personally don't plan to implement the 'simple' search, as I expect that it would not be that easy to do, while the added benefit to end users is negligible.
-
MattJ
Guus, I don't think it's negligible - many such engines will silently interpret words like "and", "or" and "not" with unexpected results
-
MattJ
and who knows what else
-
MattJ
and every server would do it slightly differently, so it's not something a user could just learn
-
Guus
MattJ: I don't think that you're wrong.
-
MattJ
My preference is strongly for simple searches, and if we were going to cut anything out, it would be the advanced searches. But I'm not arguing for that because 1) it's already implemented 2) it likely is actually useful in many cases (especially when client and server are controlled)
-
MattJ
If you actually read the Lucene query syntax, there are so many ways it could trip up an unsuspecting user who thinks they can just enter arbitrary text strings to search for
-
MattJ
Will post to the list tomorrow about my proposed changes. Good night!