Re: IMAP server side search integration
On Mon, Sep 05, 2005 at 01:53:27PM +0200, Vincent Lefevre wrote:
> On 2005-09-05 11:14:21 +0100, James Raftery wrote:
> > On Sat, Sep 03, 2005 at 10:53:09AM -0700, Brendan Cully wrote:
> > > 3. A modifier for ~b..., eg $~b or $~h, indicating that the parameters
> > > are substrings rather than regular expressions. Would people
> > > actually remember to use it or is it just a nuisance?
> >
> > This would be my preference.
>
> Me too. If need be, the modifier could be implicit when some new
> option is on.
>
> > How difficult would it be to silently use server-side substring
> > searching if the user-supplied search pattern doesn't contain any
> > regexp metacharacters ? In that case, the search modifier above
> > would only be needed to force the search pattern to be evaluated as
> > a substring.
>
> Even if there are no metacharacters, is the behavior exactly the same?
> I mainly think about attachment decoding and non-ASCII characters.
Hmm.. rfc3501 on charsets in imap server search:
The OPTIONAL [CHARSET] specification consists of the word
"CHARSET" followed by a registered [CHARSET]. It indicates the
[CHARSET] of the strings that appear in the search criteria.
[MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in
[RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing
text in a [CHARSET] other than US-ASCII. US-ASCII MUST be
supported; other [CHARSET]s MAY be supported.
If the server does not support the specified [CHARSET], it MUST
return a tagged NO response (not a BAD). This response SHOULD
contain the BADCHARSET response code, which MAY list the
[CHARSET]s supported by the server.
Cheers,
Patrick