On Tue, 30 Jul 2002 21:30:36 +0200 Xavier Nodet <[EMAIL PROTECTED]> wrote:
XN> I am contemplating implementing a 'folder moving' feature in Mahogany, XN> but I would like to have a correct idea of the work involved before XN> starting. Hi Xavier, this would most definitely be a very useful feature but the problem is that it's not very easy to do. OTOH, it shouldn't be that complicated neither if we agree on what exactly should be done. Also note that moving folders under the same parent is really trivial and the fact that dnd isn't implemented for this particular case is mostly due to my laziness (and also to the fact that I don't like to implement partial solutions when there is hope of getting a complete one in the future). XN> Issues I identified so far, in no particular order: XN> XN> 1. Filters need to be updated, in case they copy or move messages to the XN> moved folder. BTW, I guess there is problem with the existing 'Rename XN> folder' feature, here... Yes, there is. The problem is that there is no place where we store all filters operating on the given folder. OTOH, we can be pretty sure that any occurence of "full_folder_path" (with the quotes!) in a filter rule should be replace when the folder is moved and this is easy to do. XN> 2. Profile management. My initial choice would be to simply 'move the XN> profile' to its new destination. By this I mean that the profile of XN> the moved folder would become 'profile of the new parent folder + the XN> specific settings in the moved folder's profile itself'. This should XN> be simple both to implement and understand. Yes, this is the simplest to implement. I'm not/less sure about understand. For instance, note that if you move an IMAP folder called "Important" into your local group called "Important folders" it will suddenly lose its IMAP server setting -- and so on. In fact, for me this is the most difficult question. I agree that doing what you propose is simple and I can't propose any reasonable alternative myself so I'm not going to object to it but I'm nstill not sure that this is the ideal solution. XN> 3. Local file folders: I would not move nor rename the underlying XN> storage, leaving to the user the possibility to do that with 'Rename XN> folder'. Of course. XN> 4. IMAP folders: is there something in the IMAP protocol about moving XN> folders in the hierarchy? Or should it be implemented by a 'create XN> new -- move messages -- delete old' procedure? No, it's done using mail_rename() which maps to IMAP RENAME command -- it can move the folder to any other location. There are some special issues surrounding renaming of INBOX (in brief, INBOX always exists so renaming it simply creates a new folder with the given name and moves all messages from INBOX to it but doesn't delete INBOX) but other than that it should just work. Of course, this doesn't apply to moving the folder to another server. Or do you want to limit moving folders just to their "domains"? This actually might make good sense... XN> 5. Of course, all those issues must be handled for all the sub-folders XN> of the moved folder... Note that in the IMAP case RENAME renames children too, so you don't have to care about this. I also wonder if you really need to rename the physical mailbox at all when moving the folders in the tree. If it's done I'd like to have a way to not do it, e.g. if Shift or some other modifier is pressed while dragging the folder, don't do it. XN> Do you see some other things to take into account? Let's see: d&d of the folders in the tree can have different goals. I see: 1. Rearranging the folders under the same parent simply so that they appear in the way the user wants This is probably the most common case and, luckily, the simplest to implement: you simply have to write the new value to MP_FOLDER_TREEINDEX for this (and probably other) folders. BTW, the idea of storing the index of the folder position in the tree in config doesn't seem to be a very good one, so maybe we should change this... 2. Moving the files or IMAP folders without crossing the server boundary Together with 1 this should cover 90% of cases and this is indeed simple to implement. There are still problems with inheritance, i.e. you might wish to take some of the folder settings "with it" but there is probably we can do about it so your proposal (2) above seems like the good choice here. 3. Moving a folder to completely elsewhere This probably won't be very useful now, i.e. when I implement support for having virtual folders using user-specified criteria, e.g. when it becomes possible to have "Important messages" virtual folder. And implementing this is difficult. So if you want to only do 1 and 2 (which is IMHO enough) I don't think there is anything else. If you want to do 3 as well, we need to discuss it further. Bye, VZ ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ Mahogany-Developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mahogany-developers
