Hi Dave,

On Sun, 12 Jun 2022 at 13:19, Dave Cridland <[email protected]> wrote:
>
> Hey Matthew,
>
> Many thanks for this, and also many thanks for raising these on the list 
> first instead of quietly via the document author, and my apologies for a slow 
> response.

Thanks for the eventual response - I'm in no particular rush for this.
I just see people moving ahead and implementing what I see as a
mistake for the ecosystem, and wanted to provide what I see as a
better path forwards.

A large part of your response is based on the idea that I (and the
text I proposed) is advocating only an  "exact substring search". That
was *not* the intention. In particular, Postgres has plainto_tsquery
which would absolutely satisfy the requirements for simple search.
Lucene and ElasticSearch also offer similar solutions that tokenize
the input terms without any syntax interpretation. I don't see any
barriers to efficient simple text searches (they happen all the time
across most online services daily).

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.

I agree regarding the rest of your email(s). Searching against full
text indices is essential for any production service. Often these are
language-specific, which is what led me to add the language indication
in my proposal as well.

Hopefully this clarifies my intentions with the proposed changes. It
would appear we're in agreement on the requirements for efficient
searches.

Regards,
Matthew
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________

Reply via email to