Changes between Version 1 and Version 2 of BluePrint/Messaging/ExtendingParsing


Ignore:
Timestamp:
03/24/13 16:50:09 (9 years ago)
Author:
Ashwyn
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrint/Messaging/ExtendingParsing

    v1 v2  
    22[[TOC]]
    33
     4
    45The inbound message parsing framework was developed during GSoC 2012. See the [wiki:BluePrint/Messaging/Parsing 2012 GSoC message parser project].
    56
     7
    68* 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).
     9
    710
    811* 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.
    912
    1013
    11 * Things that we want to extract and are essential requirements for the framework are:
    12       * Reliability/Trustworthiness of the message sources/senders:
     14* Things that we want to extract and are essential requirements for the framework are discussed below.
     15
     16=== Reliability/Trustworthiness of the message sources/senders ===
     17
    1318                  * 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?):
     19     
     20
     21=== Actionability ===
     22
     23                  * Is this something that we can actually do something with?
    1524                  * 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:
     25     
     26
     27=== Location ===
     28
     29                  * 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 database (look the location up from the database).
     30
     31
     32=== Parsing bounced messages ===
     33
    1934                  * This is very important for IFRC Africa who send out bulk emails to their volunteer base from Eden & want to know which mails are
    2035                   mis-typed / users moved / etc