Luis Villa wrote: > [ben adida, the author of helios, is a friend of free software; I think I'm more than a friend, actually, I've been a free software developer on a number of web-related free software projects since 1998 :) > [tangentially, i did not realize the app engine dependency; i would > have been slower to recommend if i'd realized that. still, glad to > hear that there is a pgsql port in the works.] The app engine is a dependency only insofar as it provides rapid deployment and scaling. The core of the technology is all free. Toshio: I see you're going through the code with a fine-tooth comb... very nice. I look forward to more comments. I think you'll see that most of your concerns are simply (small) side-effects of the hosted App Engine setting. >> It makes some bad choices as an open source project but nothing that's >> not fixable. (Keeping local copies of third-party upstream sources >> jumps out at me immediately. Keeping partial local copies of third >> party modules and mixing those together and with the developer's own >> code makes me shiver). The only reason local copies of third-party packages are kept is because Google App Engine doesn't have them built in, so they have to be present as part of the source tree. If you have the third-party packages installed in your Python path, and you're running the pgsql version (when it's ready), you can rm -rf those third-party packages. Can you expand on what you mean by "partial" local copies, or by "mixing"? I'm pretty sure I'm not mixing any code, it's more like bundling because I can't count on the python path at App Engine. >> This is written in python with cherrypy as its object dispatcher. But >> it also makes use of django utility functions (django's local copy of >> python-simplejson :-( Also because of Google App Engine, which has django built in but not the standalone version of simplejson. Thus you see me trying to import simplejson, and if that fails I try to import the one from django. Just a couple of lines of code, though, nothing that can't be quickly fixed once the dependency is gone :) >>It looks like the Google App Engine code is >> required at the moment but it's being ported to work with a plain >> postgresql backend. I don't see signs of an ORM being used although the >> code is being ported to a home-built db abstraction layer based on the >> Google App Engine. I'm very dubious of ORM in general, both in terms of performance and transparency. I prefer dictionary wrapping of SQL results. The home-built db abstraction layer is one that I've worked on for years on many projects, and I've only just recently adapted it to Google App Engine. Also, the layer is really just a wrapper around DBUtils and psycopg2. The heavy lifting is done by those existing libraries. My API just exposes a simpler API especially when it comes to transactions and connection management. >> I don't see very much information in the app's data model for limiting >> who can vote. Voters have passwords that are auto-generated on the server side. Only voters that are listed for an election are allowed to vote. Is there something else you were expecting to see in the data model? >> I ran into tracebacks creating a new election so I'm not >> sure how it works in practice. Where, at www.heliosvoting.org? Or running it on your own? The pgsql version is not working yet. Do you have the full traceback? You can report and track the bug at: http://helios.lighthouseapp.com >> The "Java support required for heliosvoting" popup is disconcerting... >> Is that a Google App Engine requirement? This is a key feature of Helios, not a Google App Engine requirement. Java is used on the client side, in your browser, to perform ballot encryption before your ballot even leaves your browser. It is also used to generated zero-knowledge proofs that your ballot was correctly created. The key idea of Helios is that it implements security and verifiability features that go far beyond any other voting system. You get to verify that your vote actually counted, and you get a cryptographic proof of that result. Again, I want to stress: there is no other web-based voting system that provides anywhere close to this level of verifiability today. (If JavaScript had a bignum library, I wouldn't be using Java, of course.) Happy to answer any other questions, of course. -Ben _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
