On Fri, 19 Sep 2003, Henry Baragar wrote: >My belief is that the subscribed file should be createable by doing an >"ls" and then deleting unwanted mailboxes (furthermore, it would allow the >(...) >Regardless, Andy should be 100% convinced that he has made the RIGHT >design decisions before issuing version 1.2.3. BTW, this could mean that >those people that have applied the patches may have some work to do, but >it should be a non-issue to migrate from a pure 1.2.2 to 1.2.3.
Some thoughts here. Note the script suggestion.. If someone subscribes to "INBOX/folder", this would need to be stored in "file" format, which for Maildir++ means ".folder" and for IMAPdir means "INBOX.folder". This conversion is however not 1-1. A client may subscribe to "foo/", then issue an LSUB hoping to find "foo/". But in this case, it will most likely find "foo". A client is also allowed to subscribe to something that is not a file, such as a flag, in lack of support for feature X in the IMAP protocol. The server may validate the mailbox, but it "must" not. Binc does not validate it. Such mailboxes may have no filesystem representation. SUBSCRIBE and UNSUBSCRIBE are used to add and remove entries, and their arguments are today stored directly. The contents are extracted with LSUB, which shows the exact contents of the file, formatted. For this reason it's IMO more natural to store what the clients actually subscribe to, than filtered mailbox->file converted entries. However, for the convenience of adminstrators, scripts should be bundled with Binc that convert to and from the bincimap-subscribed format. Then it would be this simple to perform the ls task: ls | toimapdir > .bincimap.subscribed ls | tomaildir++ > .bincimap.subscribed The name of the scripts - I have no idea ;). I'm terrible with names. Andy :-) still listening.. -- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | "It is better not to do something http://www.bincimap.org/ | than to do it poorly."
