On Mon, 7 Jul 2003 19:55:30 +0200 (CEST) Robert Vazan <[EMAIL PROTECTED]> wrote:
> 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. So what? The idea is not that *you* can remember which message it references, but that your *computer* can. Same for identifiers for folders (and servers, and anything else): the GUI will show you the (current) name of the object, and not its ID. So I still do not understand why you would like easy-to-remember, human-readable IDs. That's what names are for... > > > 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. I do not see the point, here. What is the relation between the fact that there are many possible news folders, and IDs? > > > 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]". Understood. Not that I agree, but I see what you mean. > > 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. Any and all properties like that are to be changed via the GUI. And the GUI will show you the names, not the IDs. > 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. :-) A little bit too much, perhaps... > > 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. Don't you think that all of this is way too complicated? I'm affraid you've not given me a convincing argument for this complicated scheme. My proposal is that each folder (and other kinds of objects as well, as you say below) has an identifier that is built from the user given name. This identifier is never showed in the GUI. If you look into the registry/configuration file, you will find things like: [filter1] if (subject is "...") move to junk-2003-07-08-18-44 [junk-2003-07-08-18-44] Name=junk Type=local-file Could you please tell me exactly why you do not like this? Note that many parts of the configuration settings are already not human-readable. Many settings are integers, for which you must look at the code to understand the meaning. Would you also want to change all that? > 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. I agree. > As I think about it now, identifiers will be necessary also for filter > rules, identities, and servers [...] Yes. -- Xavier Nodet "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin, 1759.
pgp00000.pgp
Description: PGP signature
