On Fri, Mar 24, 2006 at 01:10:58PM -0000, Nigel Swinson wrote:
#1: Need to deal with nested for_every_part loops. What will this do:
for_every_part { if (some test here) { for_every_part { ... } } }
My inclination is to ban them, or at least allow an implementation-defined
limit which can be set to 1. (Actually, such a limit is allowed implicitly
for
almost anything in sieve by the base spec.)
I would like the nested for_every_part to operate on the child nodes
of the current context body part, not always operate on all the body
parts of the root message. This to me is the obvious behaviour. If Ned
wants to (understandably) ban them from his implementation, that's fine
by me ;o)
I agree. Whether script writers will actually make use of such a
construct may be in question, but I am in favor of at least not
prohibiting it. Per above, the draft could say that an implementation
must only support only 1 level of nesting but may support more.
#2: Need to decide if there would be a "mime" shorthand for testing the
type/subtype, without requiring
if allof (mime :type "multipart", mime :subtype "alternative") ?
How about getting rid of :subtype and making :type check the whole thing? A
subtype is only meaningful in the context of a particular type; the only
exception to this are suffix tags, and checking those would require :matches
anyway.
And :matches can easily be used to check the primary type by itself. I see
no
strong reason to prefer
if mime :type "text" ...
over
if mime :type :matches "text/*" ...
Although it isn't very explicit, I think I'm right in saying the
default match type for mime is "is"? So that means if :type matches
against type/subtype, then I would be very confused if I wrote :type
"text" and it didn't match against text/plain.
This because the word ":type" makes one think of "type" part of the
content type description? (i.e., with a different :tag you wouldn't be
as confused?) Personally I don't see it as all that confusing, but I
see the point, and a different :name would be reasonable.
I suggest:
- :type to match against type,
- :subtype to match against subtype
- :contenttype to match against type/subtype
Having just one that selects the entire type/subtype string, allowing
the application of different match-types to the test, would make :type
and :subtype options somewhat redundant. However, having :type and
:subtype don't really hurt, and are easy to implement. But I think the
most important point is to have an option to test the entire string,
since as I mentioned
allof (mime :anychild :type "multipart",
mime :anychild :subtype "alternative")
and
mime :anychild :contenttype "multipart/alternative"
are not necessarily equivalent (if the sub-tests of the first one match
different children). Granted, there aren't that many subtypes that are
duplicated across the mime types world, and the above is not the best
example (maybe something with "xml" would be better), but that doesn't
mean we shouldn't be able to have a reliable atomic test.
I prefer
header :mime
exists :mime
address :mime
Over
mimeheader
mimeexists
mimeaddress
ditto
-mm-