On Fri, Oct 01, 2010 at 07:42:41PM +0100, Steven Flintham wrote: > I don't know how acceptable this patch will be. > as a response i'll simply attach some correspondence with the last guy who thought he'd give it a shot. i've never heard anything from him again. ;)
--- Begin Message ---On Fri, Jan 01, 2010 at 01:24:13PM -0800, Mike wrote: > Ah, sorry - I only read the page on the web that listed the authors. > hmm, i guess i should change it then. > In that case, I'll see what I can do to make it less of a hack (if I > can find the time). > if you really want to work on that, here's the locally modified todo file as of today: add a way to automatically create and sync subfolders. read RFC3348. imap stores would have Delimiter, defaulting to NAMESPACE, fallback to /. maildir stores have hard-coded /. channel has Flatten {None|Pull|Push}: source delimiter is transformed into target delimiter or ~-(un)escaped into a (non-)delimiter. see http://el-tramo.be/files/mbsync/recursive_imap.diff what if a server says delimiter is the dot? are slashes valid in names then? check rfc3501 the actual translation would happen somewhere in sync.c. please work with the head version - it is considerably different from the 1.0 branch.
--- End Message ---
--- Begin Message ---Hi Oswald, I found some time today to read through the RFCs. On Fri, Jan 1, 2010 at 4:15 PM, Oswald Buddenhagen <o...@kde.org> wrote: > imap stores would have Delimiter, defaulting to NAMESPACE, fallback to /. I was getting worried about the IMAP server exposing several different delimiters for different mailboxes. For example, would IMAP servers exposing newsgroups have a "." delimiter for those, and "/" for normal mailboxes? (The RFC says "All children of a top-level hierarchy node MUST use the same separator character."... so I suppose they solve this by using the "#news." or similar namespace format?) In any case, I am starting to see the complexities you are concerned about. =) > maildir stores have hard-coded /. > channel has Flatten {None|Pull|Push}: source delimiter is transformed > into target delimiter or ~-(un)escaped into a (non-)delimiter. > see http://el-tramo.be/files/mbsync/recursive_imap.diff > what if a server says delimiter is the dot? are slashes valid in names > then? check rfc3501 RFC 3501 seems to assume that the delimiter will likely be either "\" or "/". See section 5.1.3, where they talk about the modified UTF-7 format and why they made the special exceptions they did. (Which brings up another note - it would be nice to translate these mailboxes into UTF-8 for storage on the local filesystem; I don't see that in the TODO file I got from CVS a day or two ago.) Interesting thought about the slashes in mailbox names. I imagine we'd just have to escape them to non-delimiters - have the user specify a character to flatten them to? Or we could skip the mailbox altogether, considering it invalid. (Realistically, do you think anyone would notice or complain?) But I don't see anywhere in the RFC that prohibits it. I think it would be a strange thing for an IMAP server to do, but it's a good corner case to keep in mind.
--- End Message ---
--- Begin Message ---hi, On Sat, Jan 02, 2010 at 07:51:34PM -0800, Mike wrote: > On Fri, Jan 1, 2010 at 4:15 PM, Oswald Buddenhagen <o...@kde.org> wrote: > > imap stores would have Delimiter, defaulting to NAMESPACE, fallback to /. > > I was getting worried about the IMAP server exposing several > different delimiters for different mailboxes. For example, would IMAP > servers exposing newsgroups have a "." delimiter for those, and "/" > for normal mailboxes? > i think this is pretty realistic. so far, isync supports only the personal namespace. if somebody wanted to sync another namespace (as well), he'd have to create a second store and use the Folder and Delimiter options. i think this is acceptable. > (The RFC says "All children of a top-level hierarchy node MUST use the > same separator character."... so I suppose they solve this by using > the "#news." or similar namespace format?) > i think that follows from 5.1.2. > > what if a server says delimiter is the dot? are slashes valid in names > > then? check rfc3501 > > RFC 3501 seems to assume that the delimiter will likely be either > "\" or "/". See section 5.1.3, where they talk about the modified > UTF-7 format and why they made the special exceptions they did. > yes, but this has no implications on what happens if it is not one of those. > (Which brings up another note - it would be nice to translate these > mailboxes into UTF-8 for storage on the local filesystem; I don't see > that in the TODO file I got from CVS a day or two ago.) > hmm, the imap spec does not say anthing about characters >= 0x100, which makes me wonder whether it really means utf-7 as encoded utf16, or only escaping 8 bit data into 7 bits with modified utf-7. though the examples are copied from the utf-7 spec, which suggests that it means real utf-7. but recoding to only utf-8 is a bit limited - one should go for proper iconv support, considering LC_CTYPE from the locale. fun fun ... > Interesting thought about the slashes in mailbox names. I imagine we'd > just have to escape them to non-delimiters - have the user specify a > character to flatten them to? Or we could skip the mailbox altogether, > considering it invalid. (Realistically, do you think anyone would > notice or complain?) But I don't see anywhere in the RFC that > prohibits it. I think it would be a strange thing for an IMAP server > to do, but it's a good corner case to keep in mind. > a correctly working server which uses a file system hierarchy internally but dots as user-visible separators would have to internally escape slashes (and additionally backslashes on windows). in reality, at least courier imap simply forbids slashes, even though the dot is its default separator. conversely, what to do about dots in names when the hierarchy delimiter is the dot? of course, courier just forbids it - there is no way to represent this in the protocol, obviously - but a name coming from a store with a different delimiter may still contain it. just like you, i've been considering allowing the user to specify how to escape things, even with regex-based substitutions. however, almost no-one would get that right. simpler to user would be a setting with a limited number of options of things to quote (delimiter only, delim + slash, delim + chars windows partitions don't like) and use a fixed custom encoding (*). i suppose one could also use the modified utf-7, but that would be illegal according to 5.1.3. (*) tilde encoding may collide with ~personal namespaces on some servers. so how about ... exclamation mark enconding?! :) !! => ! !, => . !+ => / !- => \ !; => : !( => < !) => > !_ => | !' => " !$ => ? !~ => * (note that only leading ~'s are expected to be a problem) one could also add !xx to make url-like hex encoding possible, to support escaping arbitrary delimiters (or alternatively instead of the fancy sequences above to allow storage on file systems with even more restrictions than windows). of course, one could ignore the problem entirely, indeed. >:) or at least loudly complain if a mailbox name contains the delimiter of the other end.
--- End Message ---
------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel
