On Mon, 7 Jul 2003 10:29:32 +0200 Xavier Nodet <[EMAIL PROTECTED]> wrote:
> On Sun, 6 Jul 2003 17:56:30 +0200 (CEST) Robert Vazan > <[EMAIL PROTECTED]> wrote: > > What if we come up with an identifier looking like a message ID: some > most probably unique, not too long, ascii string. I do not see any > problem with > this. I do not understand how this would not be plain text... I won't write "most probably unique" code. I would check for duplicates. Message Ids aren't readable. When you look at one, you cannot tell from memory which message it references. > > I think this can cause problems with imap folders and future usenet > > news support. > > Which problems? Instead of refering to a local file, IMAP folders refer > to a particular 'thing' (which may not be implemented by a directory) on > a particular server. Same for news. I don't use Imap. Does it mean that all folders on one Imap server must be manually added to folder tree? Or does Mahogany scan the server and add entries automatically? News has too many folders to be added automatically into user's configuration file. > > Your solution could be improved by using only path+name as > > first attempt and only add id part if path+name is allocated for other > > folder. > > Unless I mis-understand you, this would need that the references to the > folder (in the filters) must be updated. This is exactly what we want to > avoid. "Add id part *if* path+name is allocated [when folder is created]", not "add id part *when* path+name is allocated [after time]". > Then why not calling it 'Name'? Isn't that less confusing? OK, MovedTo -> Name, MovedFrom -> Id. But then, MovedTo/Name is stored outside of folder's section (where most properties are located). Maybe NameForThisId, I am not sure. > > Preferences are full of folder references that should survive > renaming. > > Preferences are just the set of values stored for a particular folder. > And if one is not found in the set of values for a particular folder, > one looks for it in the parent folder (but this reference to the parent > folder is not stored in the folder profile itself). Yes, I know this. I meant for example list of folders opened at startup or which folder is used for trash. > > .. properties of folder with id B and visible name A ... This looks like bug in SMTP or POP3 server or client. Note that there are two dots at start of line while I wrote three... I have no clue which component is doing it. > Do you mean that this newly created 'A' folder would have id 'B'? What > if I then rename this second 'A' to 'C' and create a third 'A'. Could > you please describe what the situation would be? First original: [folderA] MovedTo=folderB MovedFrom=folderB .. properties of folder with id B and visible name A ... [folderB] MovedTo=folderA MovedFrom=folderA .. properties of folder with id A and visible name B ... Then rename: [folderA] MovedTo=folderB [folderB] MovedTo=folderC MovedFrom=folderA .. properties of folder with id A and visible name B ... [folderC] MovedFrom=folderB .. properties of folder with id B and visible name C ... Then new folder: [folderA] MovedTo=folderB MovedFrom=folderC .. properties of folder with id C and visible name A ... [folderB] MovedTo=folderC MovedFrom=folderA .. properties of folder with id A and visible name B ... [folderC] MovedFrom=folderB MovedTo=folderA .. properties of folder with id B and visible name C ... Now it is getting to be interesting. :-) > The fact that it may be confusing in some (maybe unlikely) situation is > not a show-stopper. But I am not convinced that the MovedTo/MovedFrom is > able to handle all the cases, and we obviously must be able to represent > arbitrarily complicated situations... I know it requires proof. :-( The idea is to follow MovedTo links until one finds section without MovedTo property. If this enters cycle, it means there is duplicate visible name, which should be probably prohibited at Gui level. If there is section without MovedTo property, it is used as identifier -- its MovedTo property is set to newly created folder. MovedFrom links are symmetric to MovedTo, so they must be consistent too. Anyway, what I wanted to discuss is general idea of identifiers. I think that effort to improve code that updates references should be now better spent converting Mahogany to identifiers independently of how they are implemented. As I think about it now, identifiers will be necessary also for filter rules, identities, and servers as all these can be referenced in preferences and I'll need subfilter references in my planned challenge/response spam filter. It would be nice to have identifier handling code portable across different types of objects. ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Mahogany-Developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mahogany-developers
