On Wed, 9 Jul 2003 13:32:16 +0200 (CEST) Robert Vazan <[EMAIL PROTECTED]> wrote:
> OK, I think that adding some number after folder name is better way to
> resolve conflicts than my renaming chains. There are now two open
> questions:
> 1) Using visible name as default identifier whenever possible.
The reverse: using IDs as the visible name, by default. See below)
> 2) Using simple numbers (2, 3, ...) instead of longer identifiers.
Ok.
> As for the second issue, I think it is simpler, because you have to
> check for duplicates anyway. Long message ids are used when there is no
> way to check for uniqueness.
Fine.
> On Tue, 8 Jul 2003 18:48:26 +0200 Xavier Nodet <[EMAIL PROTECTED]> wrote:
> > > > > I think this can cause problems with imap folders and future
> > > > > usenet news support.
> >
> > I do not see the point, here. What is the relation between the fact
> > that there are many possible news folders, and IDs?
> My news server carries more than 100k newsgroups. If you generate Id for
> each one,
Do you read all those 100k groups on Mahogany? I guess no. So M would
only generate an Id for a group that you read because, if you don't read
the group, there is no corresponding forlder and thus no Id.
> my configuration file grows to 10MB. It's true that groups cannot be
> renamed on server (well, not right now) and it doesn't make sense to
> rename them locally,
Yes, it does. E.g. to transform a flat list with
comp.lang.c++
comp.lang.ruby
into a hierarchy with
comp
lang
c++
ruby
> but you don't want to complicate things by splitting identification
> task between server's identifier and group name. In this situation,
> it's important to keep default settings for group empty so it doesn't
> have to be stored until user does something with it.
You don't even create settings for groups that don't exist (i.e. groups
for which there is no folder created).
But I agree that for news, the ID can very well be the 'real' name of
the newsgroup (e.g. comp.lang.c++).
> > > 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.
> As I accepted idea of numeric identifiers, I think the above can be
> simplified into singe Id property. Mahogany then scans whole
> configuration for these properties and it can then tell name from Id.
>
> [...]
>
> > [filter1]
> > if (subject is "...") move to junk-2003-07-08-18-44
> >
> > [junk-2003-07-08-18-44]
> > Name=junk
> > Type=local-file
>
> There is something unusual about this. You are storing properties under
> identifier. This would require changes to code that reference folders by
> visible name.
Any code that needs some property for a folder must refer to the folder
by its ID. This is the very reason to have IDs. Therefore, Ids should be
the key under which the information is stored. Otherwise, you would have
to potentially retrieve the information for all folders to find the one
with the given Id.
> Using timestamp provides little advantage when you have to check for
> duplicates. Simple numbering scheme would be also easier to read.
Yes.
> Your example should look like this:
>
> [filter1]
> if (subject is "...") move to junk2
>
> [junk]
> Id=junk2
> Type=local-file
No, for the reasons I explained above. It is the 'Name' property that
must be optional (if it would be the same as the Id).
> This assumes there is already some folder using Id=junk. Otherwise it
> should look like this:
>
> [filter1]
> if (subject is "...") move to junk
>
> [junk]
> Type=local-file
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
