------ Original Message ------
From: "Matthew Wild" <[email protected]>
To: "XMPP Standards" <[email protected]>
Sent: 13/06/2022 15:03:38
Subject: Re: [Standards] Moving server-side MAM search forwards
On Mon, 13 Jun 2022 at 14:49, Dave Cridland <[email protected]> wrote:
On Sun, 12 Jun 2022 at 18:02, Matthew Wild <[email protected]> wrote:
What I'm trying to prevent is leaking implementation-defined esoteric
syntax to end users. That at least one implementation is already
exposing Lucene's special query syntax via this XEP is enough to
convince me that simple searches are worth pushing for.
Right, exposing something like Lucene is clearly insane on many levels.
I'm not convinced that exposing any sort of syntax is bad, though - allowing
the kind of syntax that websearch_to_tsvector allows seems harmless. But if
we're faced with people that genuinely think exposing a search language, rather
than interpreting an end-user search string, is sensible then we have clearly
lost anyway.
Yes, I agree that websearch_to_tsvector() would be absolutely fine
too. However it's not permitted by my proposed text mainly because I'm
not sure how to codify that in a XEP without beginning to dictate the
actual search syntax. Which is something I don't really want to do,
because this isn't a Postgres-driven XEP and there may be (completely
acceptable) syntax differences in other equivalent implementations.
If "simple searches" are not going to fly, maybe we could instead
settle for some non-normative text advising implementations against
exposing "implementation-specific syntax", or something along those
lines. In addition to mandating <desc> for anything more advanced than
the simple search defined in my current proposal.
If the core thing we're trying to do is ensure that implementers realise
it's not reasonable to expose an unintuitive search syntax (e.g.
Lucene's, with which I'm not sufficiently familiar to really comment),
would some text explaining that the purpose is to expose a search field
that a user can just type things into as they would a web search engine,
not to expose a structured query language, suffice? We have plenty of
evidence from the web that users can be presented with fields that can
support complex queries without being inconvenienced, where the simple
queries work as you'd expect.
/K
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
