| 1 | = Blueprint for extending the message parsing framework == |
| 2 | [[TOC]] |
| 3 | |
| 4 | The inbound message parsing framework was developed during GSoC 2012. See the [wiki:BluePrint/Messaging/Parsing 2012 GSoC message parser project]. |
| 5 | |
| 6 | * The framework is highly extensible and the parsing workflows are customisable per deployment in the templates. A nice example of this is the NLTK synonym matching filter developed during the H4D2 hackathon ( See https://github.com/flavour/eden/blob/master/private/templates/default/parser.py#L67). |
| 7 | |
| 8 | * The system supports multiple communication channels i.e Emails, SMS and Twitter.But, certainly a number of incoming feeds (so not just SMS/Tweets, but also RSS feeds, etc.) can be integrated with the system.So, plugging in the RSS feeds would be one useful step. |
| 9 | |
| 10 | |
| 11 | * Things that we want to extract and are essential requirements for the framework are: |
| 12 | * Reliability/Trustworthiness of the message sources/senders: |
| 13 | * Currently, this is done manually through the CRUD interface with the msg_sender data model. However , implementing a UI which prioritises message parsing for starred senders is also really useful. |
| 14 | * Actionability (is this something that we can actually do something with?): |
| 15 | * Its important to manage the content coming from various message sources and separate the ones that are actionable and contains useful information from the rest of them. |
| 16 | * Location |
| 17 | * An OpenGeoSMS parser already exists in the default parser template(also available as an API within s3msg.py) which is able to parse lat-lon information of the location from OpenGeoSMS formatted messages. But , it would be great if it could be linked with the locations' database. |
| 18 | * Parsing bounced messages: |
| 19 | * This is very important for IFRC Africa who send out bulk emails to their volunteer base from Eden & want to know which mails are |
| 20 | mis-typed / users moved / etc |
| 21 | |