On Mon, 6 Jun 2022, 08:56 Kevin Smith, <kevin.sm...@isode.com> wrote:
> Hi Matt, > > ------ Original Message ------ > From: "Matthew Wild" <mwi...@gmail.com> > To: "XMPP Standards" <standards@xmpp.org> > 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 ). 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. Regards, Matthew
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
