[Top] [All Lists]

Re: Final sanity check on draft-ietf-sieve-mime-loop-04.txt

2008-03-07 15:36:03

I lost track of that draft. Sorry. Three comments and a bonus.

1. for_every_part jars. We don't have file_into, we don't have any_child.

I don't mind underscores per se, but I do mind heterodoxy. Using gluedtogethernames sometimes, using underscore_names sometimes and camelCaseNames sometimes makes the language unnecessarily messy. (Yes, I know we don't have camelCase anywhere. At least not that I've noticed.)

2. break has been difficult in C for decades when nested loops are used, do we need to repeat it? Wouldn't it be better to tie break and its loop explicitly, e.g. with an identifier? The identifier would be optional on the loop and mandatory on the break.

3. Perhaps I'm tired, but it wasn't clear to me whether if two loops are nested, both operate on _every_ bodypart, O(n^2) and all, or whether the inner only operates on children of the bodypart currently accessed by the outer loop. The former seems correct, but I'm not thrilled to have O(n^2) mandatory behaviour, and O(n^m) possible if more than two levels is supported.

Bonus. Philosophy. I like the way :anychild without for_every_part works. That makes it possible to do parallel processing instead of sequential. If I want to process, say, ten or a hundred thousand messages with a single sieve script, that becomes important. I can transform the test to a database lookup and the query planner will generally do well. This makes some clever reprocessing of an entire mailbox possible. "Your new sieve script would have filed <these> messages into <that mailbox>. Do you want to move them now?". break and perhaps for_every_part torpedoes such transformations. I wonder whether that's necessary. I wonder whether it's really the same problem as the O(n^m) behaviour of nested for_every_part.


<Prev in Thread] Current Thread [Next in Thread>