- Home
- Pattern Languages
- Liberating Voices (English)
- Liberating Voices (other languages)
- Liberating Voices (Arabic)
- Liberating Voices (Chinese)
- Liberating Voices (French)
- Liberating Voices (German)
- Liberating Voices (Greek)
- Liberating Voices (Hebrew)
- Liberating Voices (Italian)
- Liberating Voices (Korean)
- Liberating Voices (Portuguese)
- Liberating Voices (Russian)
- Liberating Voices (Serbian)
- Liberating Voices (Spanish)
- Liberating Voices (Swahili)
- LIBERATING VOICES (VIETNAMESE)
- Civic Ignorance / Anti-Patterns (English)
- Other
- Projects
- Community
- Digital Resources
- News
- About
- Contact
Online Deliberation
Submitted by elemunjeli on Sun, 2012-12-09 14:19
At this point, I'm considering going back into the code, although I need to touch base with Brent and get a second opinion on the how the meeting interaction works. My first goal is actually to finish some of the UI work such as seeing organizations and being able to add members to an organization; aspects of the code I considered low priority for the demos (I don't want demo users making organizations). The data model for the profile page is sound since it only feeds dynamic data into the UI.
My next goal is to restructure a table of the database specifically for meeting state; this is the critical polling structure and I want it to be a fast convenient query without troublesome null references. I still have some design to work on here but I've definitely made progress in understanding how to structure the application vs the protocol of RROO itself. Key is the question of what data is relevant to the synchronous update. Somehow the active member of the queue should also be a part of that query. My goal is a single statement query to describe the meeting state- the active motion, who has the floor.
Next I'll work on rewriting the polling code into a long poll format. There were issues with collisions as soon as we put five users on the app at once. In my own testing, four instances ran slow, but five was a crash. Even with significantly leaner query, we need to cache.
