On Sun, 6 Jul 2003 17:56:30 +0200 (CEST) Robert Vazan <[EMAIL PROTECTED]> wrote:
> I am not sure whether the plaintext configuration is intended or it is > just byproduct of wxConfig implementation. Plaintext is useful for > debugging. Identifiers/pointers encoded into ascii isn't plaintext. > It's true that above solution would be easier to read once > implemented. 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... If the original path/name given by the user is embedded into the folder id, I suppose that it will be easy enough to read a configuration file in the standard case where folders do not move too often. > On the other hand, if you make first folder name different from > identifier, then identifier has no default and it must be > pregenerated. Generated when the folder is created, yes. > 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. Identifiers would only be used locally. The server does not know anything about it. I may have missed something, but I do not see where there could be a problem if we generate identifiers instead of setting it to the first path/name of the folder. > 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. > I didn't mean it this way. Double renaming causes *overwrite* of MovedTo > created during first renaming. MovedTo is visible name, which is a > property of folder that defaults to its identifier. Then why not calling it 'Name'? Isn't that less confusing? > > It would be much simpler to provide a function > > > > Profile* GetProfileFromId(String Id); > > > > that would be used by code modules that need to refer indirectly to > > folders > Yes, this seems easier than hacking ProfileImpl. On the other hand all > code that references folders will have to be modified (which isn't > that terrible problem). Correct. And I also think that this is not a problem. > > (the only one currently is the filter stuff, unless I missed > > something). > 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). My understanding is that this would not have to be changed, as preferences do not actually refer to any folder: they simply 'are' in a folder. > As I understand it, there is some loadable module architecture that is > likely to prevent reliable enumeration of all folder references. I'm not familiar with those modules, but if they have to refer to folders, they will do it via their identifiers. That's exactly the point. And as those identifiers will never change, I guess we're ok. > > Suppose I execute the following sequence (shown with the Profile > > informations): > > > > - Create folder A > > > > [folderA] > > > > - Rename A to B > > > > [folderA] > > MovedTo=B > > > > [folderB] > > > > - Create another folder A > > > > ??? [folderA] already exists > [folderA] > MovedTo=B > MovedFrom=B > .. properties of folder with id B and visible name A ... 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? > [folderB] > MovedTo=A > MovedFrom=A > .. properties of folder with id A and visible name B ... > Sure it looks confusing, but it's not that likely situation and > general problem always has a solution. 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... -- 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
