On Mon, 30 Jun 2003 16:09:07 +0200 Xavier Nodet <[EMAIL PROTECTED]> wrote:
> On Sat, 28 Jun 2003 12:24:02 +0200 (CEST) Robert Vazan > <[EMAIL PROTECTED]> wrote: > > > Using generated numbers looks ugly in configuration file. > > We could use path+name+id as an identifier, with path and name as to > where the folder is created, and what the user gives as a name. > > Do you look into the registry/configuration file for filters so often > that this would be a problem? 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. On the other hand, if you make first folder name different from identifier, then identifier has no default and it must be pregenerated. I think this can cause problems with imap folders and future usenet news support. 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. > > More specifically, when fodler is moved, instead of physically moving > > all properties, it gets MovedTo=<new location> property. After reading your other comments, I would correct this: When folder is moved, its properties *are* physically moved, but old and new location are marked with MovedTo/MovedFrom. This will allow old code that references folders by visible name to continue to work without changes and it will put burden of resolving identifiers on code that needs them. > Using 'MovedTo=<location>', we write down in the configuration file > the > history of changes, 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. > 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). > (the only one currently is the filter stuff, unless I missed > something). Preferences are full of folder references that should survive renaming. As I understand it, there is some loadable module architecture that is likely to prevent reliable enumeration of all folder references. > 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 ... [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. ------------------------------------------------------- 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
