[Dovecot] patch: mailboxcasecmp()
Here is a patch which adds mailboxcmp() and mailboxcasecmp() functions, similar to mailbox_equals(). Names were chosen to match strcmp() and strcasecmp(). I needed this for Johaness Berg's dspam plugin. It watches a folder "SPAM" and forcing this to be uppercase is unacceptable for me. (I also had to modify the plugin to use the new routine.)
It's against dovecot-1.0.beta8 but should be trivial to port to CVS.
-frank
On Sun, 2006-10-08 at 21:51 -0700, Frank Cusack wrote:
This works only if the underlying filesystem is case-insensitive. And I'm not sure if there are also other places where you'd have to change the checks..
Anyway, I don't know if I want to support case-insensitive filesystems right now.
On October 9, 2006 11:42:59 AM +0300 Timo Sirainen tss@iki.fi wrote:
On Sun, 2006-10-08 at 21:51 -0700, Frank Cusack wrote:
This works only if the underlying filesystem is case-insensitive. And I'm not sure if there are also other places where you'd have to change the checks..
Anyway, I don't know if I want to support case-insensitive filesystems right now.
Not sure I understand. Right now, to compare mailbox names, strcmp() is done. I take it from the source code that mailbox names are case sensitive (since in mailbox_equals(), INBOX is specifically tested with strcasecmp() if the earlier strcmp() was a non-match).
If that's correct, then the new function mailboxcmp() is just another name for mailbox_equals(), ie, it does case-sensitive mailbox name comparisons. The new function, mailboxcasecmp(), does case-insensitive mailbox name comparisons. I don't see what this has to do with the underlying filesystem, except that the list of mailboxes given to the user might depend on if the filesystem is non-case-preserving (not case-insensitive).
I don't want the dspam plugin to decide to do one action if the mailbox name (that an operation is being done on) is SPAM and another if the name is spam.
Please elaborate on your concerns. There are no callers of the new code (I only added the function, I didn't change any existing callers of mailbox_equals()).
-frank
On Mon, 2006-10-09 at 11:42 +0300, Timo Sirainen wrote:
Anyway, I don't know if I want to support case-insensitive filesystems right now.
He doesn't want to. He just wants to be able to use this in the plugin code (note how dovecot itself isn't modified) to allow a user to filter to "Spam" or "spam" or "SPAM" depending on what the user wants, etc.
Unless I misunderstood the point completely :)
johannes
On Mon, 2006-10-09 at 11:43 +0200, Johannes Berg wrote:
On Mon, 2006-10-09 at 11:42 +0300, Timo Sirainen wrote:
Anyway, I don't know if I want to support case-insensitive filesystems right now.
He doesn't want to. He just wants to be able to use this in the plugin code (note how dovecot itself isn't modified) to allow a user to filter to "Spam" or "spam" or "SPAM" depending on what the user wants, etc.
Oh. I didn't look at it that closely.
But I'm still not sure what you're going to do with a case-insensitive mailbox comparision function. If you wanted to open a Spam mailbox case-insensitively I guess you'd have to list all the mailboxes and then compare each of them case-insensitively? Or hopefully you have something else less ugly in mind? :)
Anyway I'd rather not change the code until I can figure out if the change is actually going to be a good idea. If you just want it to work now, you could just as well call strcasecmp() directly since the mailbox name comparing code won't be changed anytime soon..
On Mon, 2006-10-09 at 12:57 +0300, Timo Sirainen wrote:
But I'm still not sure what you're going to do with a case-insensitive mailbox comparision function. If you wanted to open a Spam mailbox case-insensitively I guess you'd have to list all the mailboxes and then compare each of them case-insensitively? Or hopefully you have something else less ugly in mind? :)
Yeah, we don't need to open the mailbox by name or something. All we do is check if the destination or source of a move is called "SPAM" and then we act on the move. Now, I don't mind forcing all my users to call their special spam-box "SPAM" (in uppercase letters), in fact I force it by way of a system-wide filter for spam. But Frank obviously doesn't want to force them to a given name but allow it in all possible upper/lowercase combinations.
Though, that'll probably lead to problems with the plugin when the source and destination are "SPAM" and "spam" which is certainly possible on some systems :)
Frank, maybe it'd be a better idea to just force them to "Spam"?
Anyway I'd rather not change the code until I can figure out if the change is actually going to be a good idea. If you just want it to work now, you could just as well call strcasecmp() directly since the mailbox name comparing code won't be changed anytime soon..
:)
johannes
On Mon, 2006-10-09 at 12:02 +0200, Johannes Berg wrote:
Though, that'll probably lead to problems with the plugin when the source and destination are "SPAM" and "spam" which is certainly possible on some systems :)
Yea..
Anyway I'd rather not change the code until I can figure out if the change is actually going to be a good idea. If you just want it to work now, you could just as well call strcasecmp() directly since the mailbox name comparing code won't be changed anytime soon..
And I'm really just worrying that if I add such function it could look as if Dovecot somehow supported case-insensitive mailbox names. Since strcasecmp() works only with ASCII, I'd then have to figure out what to do with non-ASCII letters to really support it correctly, and so on..
I should add support for case-insensitive UTF8 comparing though. SEARCH command should do this, and it's been in my TODO for ages.
On October 9, 2006 12:02:57 PM +0200 Johannes Berg johannes@sipsolutions.net wrote:
Though, that'll probably lead to problems with the plugin when the source and destination are "SPAM" and "spam" which is certainly possible on some systems :)
Frank, maybe it'd be a better idea to just force them to "Spam"?
hmm ... well if they had "Spam" forced upon them, and they created "SPAM" later, it still wouldn't be clear which is the magic one. I'd rather give users the flexibility to use "spam", "SPAM" or "Spam" as they see fit. It seems unlikely a single user would create multiple case-variant names. (Now that I've said that, it's practically guaranteed to happen!)
-frank
On Mon, 2006-10-09 at 03:37 -0700, Frank Cusack wrote:
hmm ... well if they had "Spam" forced upon them, and they created "SPAM" later, it still wouldn't be clear which is the magic one.
Now, maybe you just want to alter the plugin to prohibit creating SPAM/spam/spAm etc?
Then again, if you force "Spam" on them and it's always there, who'd additionally create "SPAM"?
johannes
On October 9, 2006 1:52:28 PM +0200 Johannes Berg johannes@sipsolutions.net wrote:
On Mon, 2006-10-09 at 03:37 -0700, Frank Cusack wrote:
hmm ... well if they had "Spam" forced upon them, and they created "SPAM" later, it still wouldn't be clear which is the magic one.
Now, maybe you just want to alter the plugin to prohibit creating SPAM/spam/spAm etc?
Interesting idea.
Then again, if you force "Spam" on them and it's always there, who'd additionally create "SPAM"?
The same folks, that given a choice, will create "SPAM" and then later decide they also want "Spam". :-)
-frank
On October 9, 2006 12:57:29 PM +0300 Timo Sirainen tss@iki.fi wrote:
On Mon, 2006-10-09 at 11:43 +0200, Johannes Berg wrote:
On Mon, 2006-10-09 at 11:42 +0300, Timo Sirainen wrote:
Anyway, I don't know if I want to support case-insensitive filesystems right now.
He doesn't want to. He just wants to be able to use this in the plugin code (note how dovecot itself isn't modified) to allow a user to filter to "Spam" or "spam" or "SPAM" depending on what the user wants, etc.
Oh. I didn't look at it that closely.
That's nice. Reject patches you don't look at. :-)
Anyway I'd rather not change the code until I can figure out if the change is actually going to be a good idea. If you just want it to work now, you could just as well call strcasecmp() directly since the mailbox name comparing code won't be changed anytime soon..
That seems like a bad idea (in theory). I'd have to duplicate all of mailbox_equals() which might change without my knowing about it. Better for me to keep a local patch, which will fail to apply if mailbox_equals() changes.
Sure, mailboxcasecmp() isn't ideal, but really I don't see the problem. It doesn't break anything, and it gives you the hook to fix things later if you want.
-frank
participants (3)
-
Frank Cusack
-
Johannes Berg
-
Timo Sirainen