On Wed, 8 Jun 2022 at 12:20, Matthew Wild <[email protected]> wrote: > On Mon, 6 Jun 2022, 08:56 Kevin Smith, <[email protected]> wrote: > >> Hi Matt, >> >> ------ Original Message ------ >> From: "Matthew Wild" <[email protected]> >> To: "XMPP Standards" <[email protected]> >> Sent: 03/06/2022 10:50:03 >> Subject: [Standards] Moving server-side MAM search forwards >> >> > 1) Add a "simple" search type, which is recommended to be >> >implemented as a baseline for interoperability. For simple searches, >> >the server promises that no search terms or symbols will be >> >interpreted as special syntax - what you search is what you get. >> > > If it's not a silly question - do we *need* a simple type as well as the >> default search? I think using <desc/> to describe syntax makes sense, >> but I'm not entirely sold on the need for the simple search (less so for >> it to be the recommendation) - almost all the search fields people use >> daily have special syntax (search engines, mail clients, chat clients, >> OS file search...) and by being well-crafted I strongly suspect most >> users have never clicked the syntax expansion and never realised there >> was an advanced syntax (and never suffered for it). Given that even the >> proposed simple search allows implementation-specific magic to be >> performed, would we not be better off by sticking to the one field, and >> providing helpful hints on it (maybe just <desc/>) rather than needing >> to somehow bifurcate the search UI? >> > > My expectation is honestly that the vast majority of clients will just > expose simple searches to the user, to provide the most consistent > experience. As you say, most users are unlikely to spend time getting > familiar with any advanced search syntax anyway. If they do, it's going to > be quite confusing for them if this syntax changes depending on the service > they are querying (e.g. different MUC services). > > Also, the "simple" search is easiest and safest to expose from a server's > perspective. Many of the "advanced" queries exposed by backends (e.g. > Lucene has been mentioned) are not really designed for exposure to a > general audience. It is possible to craft (intentionally or > unintentionally) malformed queries, and queries that cause excessive > resource consumption or worse ( > https://issues.apache.org/jira/browse/SOLR-11477 ). > > Believe me, you don't want table scans over the entire MAM archive table either. That nearly brought down the entire service at Pando, and we weren't even doing searching at that point.
> If you think there is still too much wiggle room for > implementation-defined behaviour in the definition of the simple search, > I'm happy to restrict it further with more wording. However I personally > don't feel that's necessary. > > To me there are many benefits of defining (and requiring) simple searches: > implementation simplicity, interoperability, user experience. Advanced > searches are potentially unsafe from a server perspective and unpredictable > from a user/client's perspective. We need more consistency in the > ecosystem, not less- and this is unavoidably a user-facing protocol feature > that clients can't easily patch a better UX over. > At the risk of sounding flippant, the likes of Google and Bing/Microsoft have managed to deliver non-simple searches very well - and yet have also not offered the "simple" search you describe at all. Google even managed to build an entire business off this strategy, all the while keeping the exact nature of their search and ranking entirely secret. Evidence really does not suggest that an exact substring search is what anyone at all wants. We have many specifications where a server can, with malignance and malice aforethought, do really stupid and unexpected things. We can advertise MAM, but with a zero retention. We can reject every stanza with a policy error. We can, in fact, do all manner of things if a server developer is actively out to get the user. Yet we still have pretty good interoperability because server developers don't do this. I don't see this as a problem that exists in practical terms. Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
