| 9 | * Just uses normal Groups & Persons? |
| 10 | * Do we need to extend these at all? (to mark that they're used for a these purposes & have some logic to identify whether all members of a group have emails &/or SMS'able Tel#s. Mark the members when we get delivery failures?) |
| 11 | * SMS Router |
| 12 | * Routes incoming message according to whether it's using specialist micro-syntax (e.g. submitting an XForm to another controller) |
| 13 | * Unidentified messages get sent to the Ticketing module's Master Message Log |
| 14 | * SMS alerts (security alerts more common than natural disasters) |
| 15 | * Being able to trigger an SMS alert broadcast upon reception of an SMS |
| 16 | * 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?) |
| 17 | * CAP alerts: |
| 18 | * http://xml.coverpages.org/OASIS-CAPv11-200510.pdf |
| 19 | * Use an XSLT? |
| 20 | * http://code.google.com/p/pyedxl/source/browse/trunk/edxl/edxl.py |
| 21 | * Subset of EDXL-DE: http://docs.oasis-open.org/emergency/edxl-de/v1.0/EDXL-DE_Spec_v1.0.pdf |
| 22 | * http://talksahana.com/2009/03/04/firefox-browser-cap-alerting-plugin-sahana-idea-for-gsoc2009/ |
20 | | Instead of having several "apps" that cross-talk, such as sms, email, tweet, jabber, etc, it would be good to have a central messaging core that has 'connectors'. This would be the equivilient of a star-hub structure. |
| 30 | Instead of having several "apps" that cross-talk, such as sms, email, tweet, jabber, etc, it would be good to have a central messaging core that has 'connectors'. This would be the equivalent of a star-hub structure. |