| | 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. |
