|Version 160 (modified by 11 years ago) ( diff ),|
Blueprint for the Messaging Framework
Table of Contents
Also see BluePrint/Messaging/Old
We would like to be able to connect to the Automatic Packet Reporting System used by Amateur Radio networks:
See the CAP Broker BluePrint
The email settings should be made web-configurable as part of the Messaging Module
- however also need to be used by Auth (order issues)
We'd like to be able to send HTML mails for rich-text support (including attachments) This requires the use of smtplib to send MIME-encoded files:
- Simple app for sending mails from a form (using smtplib): http://web2py.com/appliances/default/show/10
Support both online gateways (such as Clickatell, AWS SES or SMPP-compatible) & local hardware such as:
- a Bluetooth mobile phone
- MobiGater – Takes 1 sim card. Cost approx EUR 70.
- VoiceBlue Lite – Takes 4 sim cards and can handle 4 concurrent calls. Cost approx EUR 900.
- Multi-Tech MultiModem GPRS MTCBA-G-F4
The SMS Handler Daemon to handle Inbound messages is a separate Python script.
- Routes incoming message according to whether it's using specialist micro-syntax (e.g. submitting an XForm to another controller)
- Non-XForms messages get sent to the Ticketing module's Master Message Log
- Tagged messages also get Routed to the appropriate area (Project / Location / Organisation)
It can distinguish between simple messages (added to the Inbox of the Messaging Module) & those which are encoded in Binary XML (the output of XForms from the J2ME client).
Implementation details are here:
We use Cron to check Outbox & signal the daemon to send Pending messages (as for email)
SMS alerts (security alerts more common than natural disasters):
- Being able to trigger an SMS alert broadcast upon reception of an SMS
- Is this just an XForm to a Group? (Can we pre-populate the XForm to do this whenever a certain number is called or just a single word routes here?)
SMS login / data entry / reports
Would be good to add an LCR (Least-Cost Routing engine) for SMS deliveries (so that e.g. local messages routed via modem, but International via Gateway).
Toolkits we can base on:
- SlingshotSMS (PyGSM-based with CherryPy REST interface): http://code.developmentseed.org/slingshotsms/dashboard
- RapidSMS (PyGSM-based): http://rapidsms.org
- PySerial: http://pyserial.wiki.sourceforge.net/pySerial
- Nuntium: http://code.google.com/p/nuntium/
- Gammu: http://www.gammu.org (Python-gammu: http://www.gammu.org/wiki/index.php?title=Gammu:Python-gammu)
- Gnokii: http://www.gnokii.org (PyGnokii: http://mobilehacking.org/index.php/PyGnokii)
- Kannel: http://kannel.org (PyKannel: http://mobilehacking.org/index.php/PyKannel)
- Can be used as an SMPP gateway: http://www.kannel.org/faq.shtml#3.4
- SMSTools: http://smstools3.kekekasvi.com
Hardware compatibility databases:
- http://code.google.com/p/smpplib/ (2009/Mar 2010)
- http://sourceforge.net/projects/pysmpp2/ (2006)
- http://pysmpp.sourceforge.net (old: 2003)
Adding support for sending out/receiving alerts via Twitter & mining a hashtag for potential value:
- store tweets from 1 or more hastags e.g. #eqnz #canterburyquake to build up a local repo of all relevant tweets
- be able to reply/retweet to these messages e.g. provide an official response
- provide analytics on things like - who are the most active users and retweeters e.g. which to target for sending out messages and who is most likely to retweet
- if possible try and cluster similar/identical tweets to reduce the amount of noise - making it faster and simpler to monitor what is going on. As well as automatic clustering, it would be nice to provide users the ability to manually drag a tweet to an existing cluster so that it is removed from the master timeline (so as to simplify the timeline viewed by the user)
- be able to link tickets/actions to specific tweet
- it should be possible to automatically load a hashtag that is included in all outgoing messages e.g. we would have setup #eqnz to be included in all outgoing tweets. this may change during the event e.g. the Ministry of Civil Defence Emergency Management started with #CanterburyQuake but this was soon shortened and overtaken by #eqnz as being shorter and more useable.
- User subscribes to notifications via Twitter
- We send out alerts to a Hashtag
- Process Inbound messages to (one of) the Sahana instance's Twitter IDs
- Generic messages for the InBox
- Structured message meant for an application (create a new record or update an existing one)
- Hashtag Harvesting: A User wants to search public hashtag(s) for tweets of interest
- User has a UI to create a filter of which hashtags (& keywords?) they're interested in
- A real-time view is returned of the Tweets which match the filter (probably using JSON)
- # of matches
- 1st 10(-50?) records are browseable to see what they look like
- If there are too many/insufficient matches then user may refine the search & repeat until they're happy
- User saves the query to a msg_twitter_search table
- Option A: A single table for all queries' search results is created
- Option B: A Table is created to hold the results of the search for each record in this search table (similar to the survey module's instances)
- Cron queries Twitter & adds new records to the table as they are found
- When user opens the search results table, they can route messages to applications, e.g.
- 'This is a Request'
- 'This is an Assessment'
- 'This is a Shelter'
- Simple Web2Py example of posting/reading
- OAuth support in Web2Py
- Twitter API
- Python module
controllers/xforms.py to generate XForms automatically out of Sahana models.
These can be used by the Mobile clients for data collection.
This can be used to create OCR-able Printed Forms.
Instant Messaging & Presence including GoogleTalk:
- Nuntium - generic Channels for both Application-Terminated & Application-Originated Messaging (Ruby code from InSTEDD)
- Frontline SMS (used by Ushahidi)
- RapidSMS - also uses XForms so could be easy to integrate?
- Microsoft Vine
- Allow users to subscribe for SMS security alerts
- Ideally allow subscription via SMS too (with optional confirmation by admin staff)
- Allow security staff to broadcast security alerts by sending the alert to a single number & have it propagate on
- Security for this managed by either pre-registering their numbers as valid or by logging-in 1st
- End-users should be able to report back their status via SMS
- Security staff should receive a report via SMS of who hasn't reported in (ideally with last known Location).
- Allow team leaders to be able to send messages to their team members.
- Allow team members to select which communications means (Email/SMS/Twitter) to use for both normal & priority messages.
- Allow users to submit reports via SMS/Email/Twitter/iPadio.
- Allow users to subscribe to updates via SMS/Email/RSS.