On Thu, 2006-04-06 at 18:48 +0100, Alexey Melnikov wrote:
Aaron Stone wrote:
Now then, there's the more and more complex patterns... my suggestion is
to accept a new fact:
1. There is always a "user" part, which refers to an account
in the email system.
2. There might be a "detail" part.
3. There might be a couple of detail parts.
# 3 is an interesting idea, but I think it is taking the idea of
flexibility of this extension way too far.
The current document implies that all parts which are not "user" are in
A particular implementation can threat "detail" as a structured field,
Sieve variables can be used to extract parts of it.
The problem I see with the current approach is that it violates the
"first normal form" from database theory -- which says each field should
be a single data type and not internally formatted -- thus requiring
that the script must have intimate knowledge of how the implementation
will format the "detail" part, and requiring other extensions to extract
that format into more readily usable parts.
Although my suggestion does require that the script knows the difference
between what's in "detail2" vs. "detail3", it's at least a little bit
abstract and can be more easily documented in the mail system's script
guidelines than a series of regex extractions into variables.
Is there an extension for arrays perhaps? (or is it part of variables? I
haven't looked recently...).