eVote Adds Elections to Mailing Lists
A specialized database server for keeping votes, combined with a conferencing system, can create a medium for a true nonhierarchical democracy (see the Ideal Democracy Sidebar). The work of administering the voting system would be shared by the users and the software, not the system administrator. When the correct architecture for the problem came to me, I could no longer simply advocate Electronic Democracy; I built it.
The specialized vote server, the Clerk, is written in C++ and provides many features for voters. Anyone can initiate a poll, and users can change their votes as long as the poll is open. Polls also can be public, allowing all the participants to view each other's votes, private, or if_voted, allowing us to know who voted but not how they voted. Several poll types are supported: yes/no, numeric and grouped. The software is easily enhanced to add new features and poll types by extending the existing classes. The Clerk maintains data on the fly, requiring no help from the administrator. True to the promise of object-oriented architecture, the addition of each new feature has made the code more robust.
The ballots are dynamic. When the user closes her poll and then drops it from the conference, and when the software is otherwise idle, the ballots are collapsed, rolling the storage bytes for other items toward the top and making space for new polls. The item objects recalculate their new places in the ballots, and everything is set to continue without any intervention from the administrator.
The Clerk's main() function is an infinite loop that watches for incoming messages on the interprocess communication messaging facility from eVote clients, i.e., user-interface processes with live voting users. The Clerk has one permanent message queue for incoming requests from users, and it is managed by the single instance of the InQ class. Each eVote process has a temporary message queue of its own for receiving messages from the Clerk. These are instantiations of the OutQ class.
Although the statistics about polls and the personal information requested by a voter are communicated via the OutQ objects, another interprocess communication facility, shared memory, is used for slow-moving data. The list of poll items and their properties are stored in shared memory so that all the eVote clients currently active in the same conference can see them. Properties of the poll items may include public, private or if_voted, where users can see if another voter has voted, but not how he voted; yes/no or numeric; visible or hidden, where the statistics are available only after the poll is closed; single or grouped; and the title.
The conference's ItemList object is responsible for maintaining the shared memory. When a new poll is created for a conference, if the growing list of poll items requires a new patch of shared memory, a message is sent to all active eVote clients. This dynamic notification feature enables the voters to conduct their meeting in real time.
The Clerk keeps three data files for each conference or e-mail list and one overall data file that lists all the e-mail addresses and a corresponding numerical ID. For the sample e-mail list, a sample.dat with the current ballots, keyed by the voter's numerical ID, is kept by the BallotBox object. The BallotBox also keeps sample.bnf, which contains a hash into sample.dat and some handy statistics. A sample.inf file storing the current map of items onto the ballots is maintained by the ItemList object.
eVote, the user interface, keeps a petition's signatures and comments in a flat file, one file per petition.
At this time, the Clerk has two user interfaces and invites more. The Clerk's first user interface is a simple text-based Telnet interface, designed with conferencing systems and BBSes in mind.
The explosion of the Internet dampened enthusiasm for conferencing systems. E-mail arose as the dominant form of communication, and e-mail lists became the community discussion medium. So the e-mail user interface was built to allow e-mail communities to make formal decisions, while still using the popular Mailman mailing-list software.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Nice article, thanks for the
5 hours 2 min ago
- I once had a better way I
10 hours 48 min ago
- Not only you I too assumed
11 hours 6 min ago
- another very interesting
12 hours 59 min ago
- Reply to comment | Linux Journal
14 hours 52 min ago
- Reply to comment | Linux Journal
21 hours 46 min ago
- Reply to comment | Linux Journal
22 hours 2 min ago
- Favorite (and easily brute-forced) pw's
23 hours 53 min ago
- Have you tried Boxen? It's a
1 day 5 hours ago
- seo services in india
1 day 10 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?