Hi there!
On 28 Nov 99, at 18:26, Douglas Hinds wrote
about "Re[2]: Activating only certain filt":
> Sunday, November 28, 1999, 3:59:02 PM, Alexander wrote what follows
> below (reformatted) and I would like him to explain why the filtering
> he describes in relation to the messages he receives (all of which is
> close to what I have in mind, particularly the filtering done to those
> messages dealing with his work), can't be fully implemented in TB.
Okay, I'll try:-) Forgive me any inaccuracies you'll find in my
descriptions of how TB's filtering works, I've never used it
extensively.
1. Managing the Inbox. What essentially is done to my Inbox in
Pegasus? On every _opening_, the messages get filtered from
it to the \Unread\... hierarchy. This can be implemented with TB
all right. But then, on _closing_ of Inbox, *some* messages get
filtered to the other folders as well (such as delivery
confirmations, messages from my ISP, etc. The crux of the
matter here is that I usually just need to *see* them, but don't
need to read these, at least on the regular basis). In TB this
part cannot be implemented, therefore one would need to
implement this part as "Read" type filters. But then I would
*have* to open *each* of the delivery confirmations to get them
filtered where I want them to go to, which isn't the thing I would
like to do... In many cases, it's quite enough to *look* at the
delivery conf in the folder listing to say, where it came from and
what does this all mean. Following this idea, in Pegasus I have
set up a filter that *automatically* marks all the delivery-type
messages with pale gray colour in the Inbox, so that I could just
skip these messages... TB's filtering won't allow me this, too.
2. Dealing with mailing lists traffic. Let me remind you, that in
Pegasus the, say, TBUDL list traffic gets filtered from my Inbox
to the Unread\TBUDL folder, where it's sorted _by_thread_
(actually, Pegasus doesn't do threading, it rather sorts by
subject _and_ by date simultaneously, which only mimicks
proper threading...). There I read this traffic, and *every time i
close this folder* the read messages get filtered to
Archive\TBUDL. If I were to implement this in TB, I would
clearly be limited to using the "Read" filters. This would result in
autofiltering *each* message that I haven't deleted upon
reading to Archive\TBUDL right after I open the next message
in the folder. This is not the thing I would want to happen.
Consider the following:
a. threading would become corrupted now and then;
b. usually I read the TBUDL traffic this way: read the first
message, then either delete it or keep for the future replying;
go to the next message etc. Then when I have finished with
reading, I start replying. But in TB this would mean that the
messages I kept for replying are *already* in Archive\TBUDL:-
(( Together with heaps of older messages, some of which have
been replied to --- but some have been kept just 'coz they
contain some valuable information. Then note please, that after
I reply to some of TBUDL messages I _usually_ delete the
message itself (since I knew how to answer the question
contained in it, there is not much sense in keeping it
anyway...). Therefore with TB I would end up deleting the
messages from the Archive folder (which is set to be read only
in Pegasus right now:-) To pevent the things that you usually
put as "shit happens" out there:-))).
So well, the consideration above leads me to conclusion that
the filter moving messages from Unread\TBUDL to
Archive\TBUDL would need to be "manual only". But then there
exists another objective. Note that having "re-filtered" folder
(say, Unread\TBUDL) I would end up applying *all* my "manual-
only" filters to the Unread\TBUDL folder. Then this is a ground
to erratic filtering. Just for example: suppose someone is my
personal friend, suppose I've got a "manual only" filter
somewhere on the system moving the messages from him to
\Friends; suppose then that this person is a member of TBUDL.
Then I'm likely to filter his TBUDL messages to the \Friends
folder... An example showing the possibility of "reverse"
behaviour can be easily constructed also.
In short: the current behaviour of TB implies, that I *have* to
have all my filtering systen in mind when working with the
program. I need to consider all the time, *how* to re-filter,
*how* to set up a new filter, etc., etc --- and to be beware of
possible oddities:-). This seems to be counter-productive: in
Pegasus, I just set up a filter, check how it works and then
happily forget about its existence. Finally, in Pegasus *all* the
filters that might be automatically applied to one specific folder
are listed in one and the same place, which makes it simple to
maintain them (that is, there exists a ruleset that is applied
when the folder is opened --- and respectively a ruleset that's
applied when the folder is closed), OTOH when I choose to
apply some ruleset *manually*, I'm just choosing the desired
(single!) ruleset from the list of *all* rulesets available on the
system (all of them have of course long descriptive names...).
Needless to add that in Pegasus the rulesets are stored as
_plain_text_ files, which further simplifies bug-fixing and
maintenance...
3. The same thoughts as in 2. above are still valid when
considering the management of the work-related traffic via
filtering.
SY, Alex
(St.Petersburg, Russia)
--
Thought for the day:
The only difference between the fool and the criminal who
attacks a system is that the fool attacks unpredictably and on
a broader front.
---
PGP public keys on keyservers:
0xA2194BF9 (RSA); 0x214135A2 (DH/DSS)
fingerprints:
F222 4AEF EC9F 5FA6 7515 910A 2429 9CB1 (RSA)
A677 81C9 48CF 16D1 B589 9D33 E7D5 675F 2141 35A2 (DH/DSS)
---
--
--------------------------------------------------------------
View the TBUDL archive at http://tbudl.thebat.dutaint.com
To send a message to the list moderation team double click here:
<mailto:[EMAIL PROTECTED]>
To Unsubscribe from TBUDL, double click here and send the message:
<mailto:[EMAIL PROTECTED]>
--------------------------------------------------------------
