Re: [OVC-demo-team] Latest update for BRP

From: Fred McLain <mclain_at_zipcon_dot_net>
Date: Thu Mar 11 2004 - 22:51:43 CST

On Wed, 2004-03-10 at 19:38, Eron Lloyd wrote:

Hi Eron & all,

> 1. In Jan's example code
> (, the
> write-ins don't get decoded. In the documentation I think I recall them
> simply being given a boolean state in the barcode. If this is the case, why
> are they instead explicity declared instead of being read from the barcode
> (in the example)? How do I handle this?

Alan tells me that it's OK that the write-ins don't get encoded to the
barcode. He can expand on this further.

> 2. Have we settled on using the gnosis.xml.objectify function to convert the
> XML files to an intermediate data structure for comparison? Also, precisely
> what should the comparison process to? A simple boolean A == B?

Using these tools is OK and should help. David wrote them, he can help
with details on using them.

> 3. Exactly how should I expect the ballot data to be read and from where?
> Right now I simply look to /dev/cdrom/. I'm thinking that it would be easy to
> simply pull a serial.txt file to identify and register each disk. Will this
> be OK? Should each disk get transferred to a separate directory on the hard
> drive, or can they all merge together? (can we guarantee that level of
> randomness in the filename?)

Pick a directory to use for the ballots, (i.e. ~/evmdata), we won't be
reading off CD for the demo. The serial.txt sounds fine.

> 4. Has anyone produced a test suite of sample ballots? I'd actually like two:
> one with errors, and one without. I imagine a suite consisting of a number of
> XML files (and their PS/PDF output) along with a text file listing each
> ballot's serial output. If someone could do this and package it up, that
> would be a big help. I know there we a couple changes that were pointed out
> in David's script, but I'm not sure if they were addressed yet (like the
> ballot number padding, etc.).

David wrote a tool to generate the sample ballots. His post about this
was last Saturday the 6th with attachments containing the files. I'll
forward it to you.

> 5. What kind of output do you expect to have from the reconciliation report?
> Do you even want anything other than what the UI will display? Should the
> poll workers be able to log out even if everything doesn't even out?

Alan is digging up the spec now, it's on the OVC list somewhere.

> 6. I have the ability to be able to log just about anything that is done
> during the process. Is this desireable to have?

Logging is good. Logging is your friend :) Logging is also very handy
for debugging setup problems when you're miles away. Go ahead and log,
even if it's verbose.

Please send me your phone number in an off list mail and we'll chat more
about this on the phone as needed. The demo date is rapidly

We do still need the missing files as well:
> > It also appears I am short some files:
> >
> > [mclain@glowtoy bva]$ python
> > Traceback (most recent call last):
> > File "", line 703, in ?
> > wizard = BRPWizard()
> > File "", line 251, in __init__
> > self.authHandler = AuthenticationHandler('acl.txt') # Right now we
> > assume acl.txt exists
> > File "", line 155, in __init__
> > self.loadAccessControlList(fileName)
> > File "", line 159, in loadAccessControlList
> > self.__acl = dict([acct.strip().split(';') for acct in
> > file(fileName, 'r').readlines()])
> > IOError: [Errno 2] No such file or directory: 'acl.txt'
> acl.txt is a simple text file that holds the Access Control List. This is the
> basic authentication source for the BRP. There is no encryption or anything,
> but I could easy plug that in if demanded. This is supposed to just be a
> simple demo, so please don't judge my security-consciousness solely on the
> code :-). To make it work, simply create a acl.txt file in the same directory
> will be run from. Populate it with a list of potential BRP
> operators/witnesses, using the username;password<line break> convention.
> The code also looks for a votestations.txt file, which list the serials of
> each vote station, each on a separate line. Add this to ensure proper
> operation as well.
> I don't have many integrity or error checks in place yet either; I will add
> robustness as seen fit. If the program crashes from some reason during the
> process (I can't imagine it would if ran normally), all is lost; nothing is
> transaction-based, and won't be for the demo. Essentially, the code is about
> as simple and straightforward as I could make it. It's really hard *trying*
> not to write good, solid, well-designed code when I try to make it a habit.
> (to paraphrase the Pope): It is what it is.
> Eron
> ---
> [This E-mail scanned for viruses by Declude Virus]
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Thu Apr 1 02:40:26 2004

This archive was generated by hypermail 2.1.8 : Thu Apr 01 2004 - 02:40:36 CST