<p>I am working on some significant enhancements to the current architecture and trying to plan how to make it flexible. Some of the changes include:</p>
<ul>
<li>Embedding gnokii directly using the Rubynokii library and libgnokii directly</li>
<li>Handling multi-message “sessions”</li>
<li>Handling authorization</li>
<li>Other features</li>
</ul>
<h2>Embedding gnokii</h2>
<p>This should be a pretty easy challenge as most of the work is already handled by “Rubynokii”=http://github.com/thyagarajan/rubynokii/tree/master (Github). The primary challenges are initializing and finalizing the bus and port for the connected cell-phone. In the standalone console application this is easy, however in the daemon this is more difficult as the daemons gem does not support setup and teardown modes. To work around this, the daemon will handle two additional command line parameters: “connect” and “disconnect”. If it receives either of these it will perform the appropriate server commands and exit.</p>
<h2>Handling multi-message “sessions”</h2>
<p>Initial implementation is already underway and is simple. As a message comes in the handler needs to check to see if the incoming message is a command. Based on the command, the handler will handle the text.</p>
<p>If there is no session currently:</p>
<ul>
<li>Check for a template name (the example template is “<span class="caps">HTC</span>” for <span class="caps">HIV</span> Testing and Counseling)</li>
</ul>
<p>If the template name is found in the list of templates, a new “entry” is started and the first question is added and sent as a reply. If the template requires a person identifier to be associated with it, the first question should be to enter the person identifier.</p>
<p>If their is an existing session (based on whether or not there is an active “entry” that has not timed-out), then you need to check for a session command:</p>
<ul>
<li>Cancel</li>
<li>Skip</li>
<li>Help</li>
</ul>
<p>If the command is “cancel” then the entry is marked as canceled and the handler exits. If the command is “skip” then the question is skipped and the next question is sent as a reply (it may be possible to add a <ins>allow_skip</ins> flag to the question). If the command is “help” then a more advanced “help” text is sent (possibly multi-part) if it is available, otherwise “no help available” is sent.</p>
<p>If there is an existing session and the incoming message is not a command then it is assumed to be an answer. Answer validation should be available based on a set of common classes (numeric validator, cell validator, weight validator, person identifier validator, etc.) If the answer is validated then it is saved and the next question is asked of the client. (/Note/: do we need answer parsers for multi-answer responses or should this be saved for another layer).</p>
<h2>Authorization</h2>
<p>In addition to “Workers” using the system, we will probably want to allow each “Person” to access their own content. They may want to do this to check their appointments, get drug/prescription information and may other commands. Because of this we have to allow for the registration of people and their cell phone numbers. Because phones are often shared patients should also need to enter their identifier so that the correct information is given. This raises [[security]] concerns as the identifier might be associated with a particular person based on eavesdropping.</p>
<h2>Other features</h2>
<p>Trying ot to lose focus I have held off on the following features. I wanted to list them here for reference. Please add any that you would like to see:</p>
<ul>
<li>Daily broadcast messages</li>
<li>Groups and group messages</li>
<li>Giveaways/Contests</li>
<li>Self registering (no worker needed)</li>
</ul>
2008-10-31T10:00:02-07:00
74810
future
67852
Future
2008-10-31T10:11:14-07:00
4064