Re: Debian Project Leader Elections 2007: Draft ballot
On Tue, 27 Mar 2007 13:43:31 +0200, Josip Rodin <joy@entuzijast.net>
said:
> We strayed from the real point here... the point is that these
> internal variables are completely irrelevant to the voters and
> should be avoided. The program can detect the line "[ ... ] Option
> name" just as easily as it can detect "[ ... ] specialstring: Option
> name".
This by itself is not justification enough. The fact that the
ballot provides redundant information that is irrelevant to the
users, but in turn eases parsing of potentially MTA mangled ballots
seems like a win. Given that ballots can be word wrapped, can have
common leading text, might have words that are damaged by MUA's not
encoding a non-ascii word identically; it makes sense to increase the
robustness of the parser by giving it a well known, unique prefix.
Also, the current implementation optimizes for potential
re-sorted ballot lines by using the Choice N string to determine
which index in the options array the ranking is referring to; and I
do not see enough of a reason to refactor the code.
So, if some one can demonstrate to me that the parser will not
become less robust, and that the new code is equally resilient to
MUA mangling of ballots, and that the increased complexity of code
does not impact future maintenance, and that all this effort has a
tangible benefit --- I'll consider reevaluating this design decision.
manoj
--
O'Toole's commentary on Murphy's Law: Murphy was an optimist.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: