On Tue, Nov 06, 2007 at 12:37:21PM +0100, Christian Brabandt wrote:
> here is another patch, that tries to use whatever folder separator
> works.
Thanks for reminding me about that. I think this deserves to be fixed
in 0.7.1.
Your patch assumes that there are only two folder delimiters out there,
but unfortunately this does not hold. According to the spec, *any*
character can serve as a delimiter; it seems that at least '/', '.' and
'\' are popular.
> --- /home/chrisbra/bin/archivemail.orig 2007-11-06 12:08:32.000000000
> +0100
> +++ /home/chrisbra/bin/archivemail 2007-11-06 12:27:52.000000000 +0100
> @@ -1434,9 +1434,23 @@
> result, response = imap_srv.login(imap_username, imap_password)
> vprint("logged in to server as %s" % imap_username)
>
> + # imap folder separator detection
> result, response = imap_srv.select(imap_folder)
> - if result != 'OK': unexpected_error("cannot select imap folder; "
> - "server says '%s'" % response[0])
> + if result != 'OK':
> + if string.find(imap_folder,'/') != -1:
> + vprint("Hmm, '%s' does not work. Maybe we need to use a different
> folder separator? Let's see" %imap_folder)
> + vprint("Trying '.' as folder separator")
> + imap_folder=string.replace(imap_folder, '/', '.')
This looks like a reasonable guess.
> + elif string.find(imap_folder,'.') != -1:
> + vprint("Hmm, '%s' does not work. Maybe we need to use a different
> folder separator? Let's see" %imap_folder)
> + vprint("Trying '/' as folder separator")
> + imap_folder=string.replace(imap_folder, '.', '/')
This assumes that the user has meant the dot to be a delimiter. That
is, the user has tried to guess the delimiter himself, and didn't
succeed if we're reaching this point.
I think we shouldn't try to fix such wrong guesses. There are two input
variables: the delimiter in the user's URL, and the 'real' server
delimiter. We have to map the first to the latter.
If we really don't want to support servers using uncommon delimiters, we
could indeed just try the common delimiters in turn. In any case,
trying to fix wrong guesses by the user gives us a multiple of possible
mappings.
It's better to first try what the user has specified, and if this fails,
then replace slashes in the mailbox name with (possible) delimiters.
But I don't like the idea to cover only the common cases with such a
try-and-error procedure anyway. I think I do have a correct and generic
solution for this in subversion now. It's not completely trivial, but
it should work.
Thanks,
Nikolaus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
