[spambayes-dev] RE: [Spambayes] Accidentally deleted Junk
tim.one at comcast.net
Thu Dec 18 14:46:16 EST 2003
>> I wonder whether the Outlook addin should stop trying to remember
>> Outlook's internal folder IDs, remember the user-visible string
>> paths instead, and enumerate the folders to (re)discover the
>> internal Outlook IDs "whenever anything may have changed".
> I'm not sure what you had in mind for "anything may have changed",
In the limit, I suppose that means finding the folder object again from
scratch every time a folder object is needed. Anything else is just
> but in general, I agree. I always had the idea that we would also
> store the FQN, and fall back to that when necessary, making the
> folder ID more a "cached" value. It just never happened. It does
> get complex though - what happens when the user renames the folder?
> Before you know it, we have even more cruft that noone really
> understand why is there <wink>
It's a part of Outlook's model that doesn't make sense to people. When my
sister, for example, renames or moves a folder holding Word documents, she'd
be baffled if Word *did* magically notice this. The idea that a data object
is accessed by, and only by, its current "string path", has been beat into
her by Explorer, by all the other Office programs, and-- for that
matter --by all other programs she uses too.
Outlook is the oddball exception here, but only wrt its internal objects. I
remember how surprised *I* was the first time I changed the name of a folder
that was the "move to" target of an Outlook rule, and the rule kept moving
things into the renamed folder; I had expected Outlook to screw up, or at
best to pop up an error box the next time the rule conditions fired, telling
me the rule no longer made sense. That would have been fine by me.
So we can play along with Outlook's model, and have 99% of our users wonder
why SpamBayes deletes all their email <wink>, or match the mental model
everyone (except Outlook experts) has from the start. I agree they're
deeply incompatible, but each gives a clear answer to questions like "what
happens when the user renames the folder?".
> Another alternative would be to change things so that most errors
> re-displayed the config wizard.
I'm not sure how that could help. The problem people have now is that there
*aren't* any "hard" errors after they delete their Spam or Unsure folders by
mistake -- SpamBayes plays along with Outlook's "the name and path are
irrelevant, I still know where the *object* is", and users have no idea
Outlook works that way. What they do instead is create a new Spam folder
directly under Personal Folders, and then are baffled again because that
doesn't work either (for the same reason -- they're thinking of string name
and path, not Outlook object identity).
> Either way, I'm going for a new combined binary before this even gets
> a look in <wink>
More information about the spambayes-dev