--On Thu, Jan 21, 1999 4:34 PM -0800 the entity known as Randall Gellens
<randy(_at_)qualcomm(_dot_)com> wrote:
I see fileinto as an action that
determines into which mailbox this message is placed. On "classic"
message store systems there can be only one such mailbox per message;
to put the message into additional mailboxes requires copying. On
systems that implement single-copy message stores, it may be simple
to logically make the message part of any number of mailboxes, but I
don't think that should drive Sieve semantics.
So, only one fileinto per message. Anything else is a copy, which is
separate (and should be optional).
To which Matthew Wall writes on Thu, 21 Jan 1999 19:46:08 -0500:
au contraire. I think a "copy" is "cloning" an original (usually from disk
or static store), whereas a fileinto is typically done from memory
dynamically at the "delivery" event, like giving birth to twins. The
distinction is making a copy versus making multiple instantiations of a
single original. Whether there's a difference in the actual storage of the
message or not may not be an important one, but I'd maintain a message
might change between the time it's initially filed and then copied.
This is what I'm thinking the state difference is:
message is delivered ---> fileinto messagestore A --> copy from A to B
e.g.
+----------+
SMTP ---> | SIEVE | ---> fileinto A action -->
RFC/822 +----------+
+----------+
---> | SIEVE | ---> copyaction A to B
+----------+
(Randy's model, as I understand it)
vs.
+----------+
SMTP ---> | SIEVE | ---> fileinto A
RFC/822 +----------+ ---> fileinto B
(the way I see a simple multiple fileintos as Larry described.)
The former model isn't so strange if you think about the client being the
Sieve engine, with full access to and knowledge of the mailstore. Easy
enough if you're talking about an IMAP append (although with the state of
the message not necessarily the same in the COPY scenario -- think about a
"seen" flag, for instance -- not reliably the same kind of message) or a
copy on a local POP store. But I don't think you can assume that SIEVE will
know enough about the store to do a copy. Let's say the fileinto action is
meant to flag certain messages for delivery to a user (primary function)
but alert a system adminstrator (say, a potential candidate for Spam) as a
secondary recipient. The mailstores for the two of them may be different.
Anyway, I'd argue multiple fileinto is simpler, since it only requires
three "steps" for completion instead of five. (Please, no comments about 11
being louder than 10.)
There is nothing in particular implied by the order of
the Sieve statements.
my turn to be dense 8-). I again make a distinction between an ordered
series of fileinto actions vs. a single fileinto action into multiple
stores (mailboxes) which you may not. The very fact of a fileinto itself
may be an important artifact of a single fileinto or test.
Here's a pseudo-script.
file X into --> A
file Y into --> B
copy X from A --> B
assume there's an ultra-precise timestamp on a message. Let's pretend A is
a private mailbox, B is a shared one.
Yes, there's no order implied by Sieve, but implementations will have a
specific order.The time 'received' or the recent flag or whatever is going
to be different for the same message in the above two scenario.
With multiple fileintos, it would be more like
file X ---> A and B
file Y --> B
Thus the state of X is the same in A and B at the time (in whatever order)
the Sieve script is executed.
I just find this a cleaner model for single-line execution, bearing in mind
that implementations (like Larry's) are free to treat (and resolve) all
actions as aggregates rather than as a linear sequence.
I can also see, from the history of FLAMES, why this is important to not
assume linear exection.
How is (multiple) FileInto more obvious than CopyInto?
MultipleFileinto implies a single event of delivery to multiple
destinations. Copy (to me, at least) implies a delivery, then a copy of
that original. It's two events, not one.
In my implementation, Sieve operates as a plug-in, and gets to set
the destination mailbox. So it can only do one fileinto (at least as
the API is now). If that fileinto can't be honored (the mailbox
doesn't exist), the delivery agent uses INBOX as the default.
Yah, you're right, this is consistent. I'm saying if there's a
multipleFileinto where one fails, there should be a default fileinto
behavior as for singleFileinto. (I don't mean to suggest these as actual
names.) However, since I haven't thought through syntax issues for a
proposed new command, I'm not sure I know whether this should be different
from the current behavior or not.
I actually just want fileinto to be allowed to go to multiple mailboxes,
but if we can't require that, I don't like the concept of a "copy" if we
need to remove the requirement for multiple fileintos for the above
reasons...
- matt