This is an old revision of the document!
Table of Contents
Sahana Messaging Architecture
The Sahana Messaging architecture follows some important goals
- Standards Based
- F/OSS Component Reusability
- Implementation independent plugin-architecture
Messaging in Sahana is currently implemented as a module under <sahana-folder>/mod/msg.
The Sahana Messaging is designed with reuse and standards in mind.
Overview Architecture
Features of the Current Messaging Module
- Module independent API for external modules
- Developer is able to use the API independently regardless of the actual plugin or data used.
- Plugin architecture similar to the Sahana framework which automatically detects and handles Messaging plugins
- Messaging framework and administration section with plugin architecture
- Kannel plugin
- SMSTools plugin
- Ability to send SMS or e-mail to Groups from templates
- CAP Alerts
- Surveying: Conduct surveys by sending survey questions: receive responses as survey reports
- Advanced Contacts management
- Auto-refreshing SM receiving interface
Features of the Proposed Messaging Module
To be delivered by GSoC 2008:
- Ability to access Sahana via SMS menus
- SMSd event handler able to lookup Sahana DB access details from sysconf.inc
- Login menu: user,pass
- State held in server based on CallerID: Login name, menus status
- Modules are able to write scripts for the SMSd event handler to access via a new lib_form_sms.inc
- each module has a sub_dir to avoid name collisions
- Users have 2 modes:
- Basic users answer a single question per txt
- Expert users can choose to answer multiple in 1 go:
- 1,3,4 would take them to Module 1's 3rd menu option & then select option 4
- lat x.xxx,lon y.y.y.y,desc “Bridge Down”
- Query Data in the Sahana DB
- Showcase example: “tbc”
- “List Situations within xxx of my current GPS coords”? (Do we have a GIS query for this?)
- Input Data to the Sahana DB
- Showcase example: “Add new Situation to Situation Awareness Module: GPS coords & details”
- Admin UI to enable/disable forms
- Reuse GIS layers' approach: 1 tab per module, table of available forms for enabling/disabling
- Top-level controller for the top-level 'Which Module?' menu
- Admin UI aware of scripts via conf? Or simply reading scripts from filesystem? (Metadata included in scripts)
- Windows Installer for SMSTools
Bugs:
- plugin selection doesn't show status of current plugin (see GIS plugin to fix this)
- Admin UI for Kannel Plugin to use admin_settings.inc from plugin folder not root
Potential deliverables
- More advanced admin UI for SMSTools Plugin
- Multiple/Parallel modem management
- Telco specific message routing: routing messages based on number (with multiple modems on different networks)
- Localized Messaging: Ability to select language to send (also mobile interface to support receiving localized content? )
- Keyword Management: select quick contacts based on keywords…
- MMS Integration
- SMS alerting channels: users can subscribe to channels to receive SMs. Subscription can be done by SM itself ?
- Situation Alerting: receive and store coordinates
To be delivered later:
- Gnokii plugin (to use Symbian phones without full AT commands)
- Clickatell plugin (for bulk SMS without own hardware)
Potential Existing Projects
- PlaySMS - GPL, not LGPL