Polly/Design

Source Code Hosting
Github - An initial empty project has been created: https://github.com/ppau/polly

License Agreement
Creative Commons 0: http://creativecommons.org/publicdomain/zero/1.0/

Client Side Technology
Probably JavaScript/AJAX style interface. Maybe Coffee.Script for simplified coding. HTML5? I can help with this - jscinoz  Awesome - AndrewD Ab: I can help with some of this as well. Mobile clients are a non-requirement for now. Maybe a future project. - Brendan

Server Side Technology
Up for some investigation right now. AndrewD: Looking at django -> django-mongodb -> mongodb

Database
Thinking about NOSQL options. ref: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

What's wrong with MySQL? - Chris AndrewD: The problem is not so much MySQL as SQL in general. An entire job description (DB Administrator) exists because of what is wrong with SQL. Coding to SQL is not hard and relational theory is all well and good, but the administration inherent in the whole approach just sucks. Why do they have to be so rigid? It's built on 1960's assumptions of waterfall style development practices, upgrade cycles and planned down-time. SQL started out with a goal of making databases accessible to non-programmers, but that never really happened and the programmers end up writing queries in a declarative language, then reading the query optimizer results to figure out why it's not implementing things the efficient way they imagined it would when they wrote it, instead of just describing what they want to happen. It's stupid. Then, when you want to roll out a new version of your application, you have to take it all down and convert everything in a carefully planned series of rehearsed activities. Then there's scaleability. SQL just sucks at that. You have to design distribution in from the start, or else a successful application runs into a massive roadblock, but designing it in fron the start just massively complicates your original development. ORM is just an attempt to reconcile the object based way we like to work in our applications, with an archaic old way of storing things.


 * Likely
 * Mongodb
 * Python & JaveScript, JSON/BSON, django interface
 * Replication, HA, Sharding built-in
 * Map-Reduce
 * Neo4j
 * Looks like a good fit to the style of data relationships we probably want.
 * Java & Ruby primarily, but has Python interface (neo4j-embedded)
 * Full ACID conformity!
 * Not Likely
 * Riak - Multi-site requires commercial license. Crystal ball suggests this could be bad for us.
 * CouchDB - Pre-defined queries and limitations on data format change are show stopper for me.
 * Redis - "Should fit mostly in memory". Scaling issue right there.
 * HBase - Hadoop based (Java & Ruby). Sledgehammer - requires its own file system.
 * Cassandra - Strongly Java centric, "Bloat and complexity". No thanks.
 * Membase - Seems very performance centric, scaling and distribution, but doesn't look strong on data integrity (responds to client before writing)

Encryption
HTTPS for all requests - Brendan. +1 - Chris I'm technically OK with HTTPS for everything, but it costs a lot of server processing time or front end equipment. Maybe we can design with configuration that says whether to turn on HTTPS for read/write/both - AndrewD

Authentication
Quoting: http://en.wikipedia.org/wiki/Multi-factor_authentication "Existing authentication methodologies involve three basic “factors”:
 * Something the user knows (e.g., password, PIN);
 * Something the user has (e.g., ATM card, smart card); and
 * Something the user is (e.g., biometric characteristic, such as a fingerprint).

I'm recommending a loose kind of 2-factor authentication. Would be associated with their account, but not exposed to other people. A daily(or on specified frequency) log of account activity would be notified to the users email account.
 * Factor 1: UserId and Password  (Something the user knows)
 * Factor 2: External email account (Something the user has)

This strategy keeps the simplicity of regular user logon for access, but applies our principle of "Self Evident Integrity" to ensure any breach is rapidly known and corrected. The system becomes self-healing.

---

Some original Brendan notes... Herein lies the implementation requirements for a successful liquid feedback system from a technical standing point.

Backend

1) Must Python backend Operating Systems: Linux Mac OS X Multiple SQL support: MySQL pgSQL MSSQL

2) Want Use of ORM Operating systems: Windows FreeBSD OpenBSD NetBSD Very strong anonymity implemented with that crazy crypto we use in other system (Ab: AES256?)

3) Can

4) Wish Operating Systems BeOS MS-DOS

Frontend

1) Must Localisations

2) Want Python webapp (Django?)

3) Can

4) Wish