Changes between Version 2 and Version 3 of Event/2012/GSoC/MessageParsing


Ignore:
Timestamp:
05/14/12 17:17:57 (12 years ago)
Author:
Ashwyn
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Event/2012/GSoC/MessageParsing

    v2 v3  
    1 === 1. Personal Details ===
    2  
    3 *Name:  Ashwyn Sharma
    4  
    5 *Email: ashwyn1092@gmail.com
    6  
    7 *Freenode IRC Nickname: ashwyn
    8  
    9 *Skype: ashwyn sharma
    10  
    11 *Age:19
    12  
    13 *Education: Currently pursuing B.E.(Bachelor in Engineering) from N.S.I.T, New Delhi.
    14  
    15 *Country:India
    16  
    17 *Timezone: GMT +0530
    18  
    19 *Linked In Profile: http://in.linkedin.com/pub/ashwyn-sharma/37/bb2/777
    20  
    21 *Exposure To Similar Technologies and/or  FOSS in general :
    22  
    23 *My work experience with FOSS was pretty limited (when I started to contribute for Sahana), but I have  spent a past few years developing a great understanding of its modus operandi , thus giving me a sufficient exposure to the whole concept of Free Open Source Software (FOSS).However , my involvement with the Sahana Software Foundation for the last two months has given me tremendous experience with Python and the web2py technology in particular.
    24  
    25 *Why would you like to help the Sahana project?:
    26  
    27 *As we rightly know that the Sahana Software Foundation enable organisations and communities to better prepare for and respond to disasters.In the process,they save a million lives  through its information management solutions. Contributing to a cause as noble as this just adds that extra motivation or rather a purpose behind all the coding and development process that goes on during the summer. Living in a country like India which is prone to several natural hazards and disasters ; and having witnessed one myself in  http://en.wikipedia.org/wiki/2001_Gujarat_earthquake ,it makes me understand the need of a deployment tool like Sahana Eden in a more realisable way. Moreover, I really believe that my work with the Sahana community so far helps me contribute to Sahana and the Eden Project in particular in the coming future.
    28  
    29  
    30  
    31  
    32  
    33  
    34  
    35 === 2. Personal Availability ===
    36  
    37 *Have you reviewed the timeline for GSoC 2012?
    38  
    39 *Yes,  I have reviewed the timeline for GSoC 2012.
    40  
    41 *Do you have any significant conflicts with the listed schedule? If so, please list them here.
    42  
    43 *No,not really.My semester exams are in the second half of May,2012.However, the coding starts on 21st May according to the timeline.So, I will not be losing any significant time.Moreover, I would be more than happy to start coding before that period so that I will be able to compensate for the few lost days
    44  
    45 *Will you need to finish your project prior to the end of the GSOC?
    46  
    47 *No, my project  is planned to be developed along the whole summer.
    48  
    49 *Are there any significant periods during the summer that you will not be available?
    50  
    51 *Apart from the conflict listed above, I will be completely available throughout the summer
    52  
    53  
    54  
    55  
    56  
    57  
    58  
    59  
    60 === 3. Project Abstract ===
    61  
    62  
    63 *The essential requirement for this project is to parse inbound messages , with an initial focus to SMS. The project is specifically aimed at the CERT usecase  where they wish to process responses to deployment notifications. Or in other words , to handle replies to deployment requests. Currently  the message parsing is done in the core code i.e. modules/s3/s3msg.py ,to be particular, in the parse_message() method. The parsing rules will be defined in private/prepopulate which allows for hosting of multiple profile options in the main code.Now,s3parsing.py can import these parsing rules from prepopulate.This also enforces the on-going work in the development of the Profile Layer , in which deployment-specific files are separated from core code.The parsing module utilizes a data model "msg_workflow”  to link the source and the workflow to schedule tasks. Processing of OpenGeoSMS encoded messages is also an important area to work on especially for the existing Android Client, for which it will be of real use. Also to provide robustness and extend the existing code , the pyparsing Parser module can be incorporated or any other parsing generator ; which will be subjective to the parsing needs.
    64  
    65  
    66  
    67  
    68  
    69 === 4. Project Plan ===
    70  
    71 *'''Project Deliverable:
    72 '''
    73 *The project aims at parsing inbound messages such as SMS from CERT responders after deployment.
     1==1. Personal Details==
     2 
     3Name:  Ashwyn Sharma[[BR]]
     4
     5Email: ashwyn1092@gmail.com[[BR]]
     6
     7 
     8Freenode IRC Nickname: ashwyn[[BR]]
     9
     10 
     11Skype: ashwyn sharma[[BR]]
     12
     13 
     14Age:19
     15 
     16Education: Currently pursuing B.E.(Bachelor in Engineering) from N.S.I.T, New Delhi.
     17 
     18Country:India
     19 
     20Timezone: GMT +0530
     21 
     22Linked In Profile: http://in.linkedin.com/pub/ashwyn-sharma/37/bb2/777
     23 
     24Exposure To Similar Technologies and/or  FOSS in general :
     25 
     26My work experience with FOSS was pretty limited (when I started to contribute for Sahana), but I have  spent a past few years developing a great understanding of its modus operandi , thus giving me a sufficient exposure to the whole concept of Free Open Source Software (FOSS).However , my involvement with the Sahana Software Foundation for the last two months has given me tremendous experience with Python and the web2py technology in particular.
     27 
     28Why would you like to help the Sahana project?:
     29 
     30As we rightly know that the Sahana Software Foundation enable organisations and communities to better prepare for and respond to disasters.In the process,they save a million lives  through its information management solutions. Contributing to a cause as noble as this just adds that extra motivation or rather a purpose behind all the coding and development process that goes on during the summer. Living in a country like India which is prone to several natural hazards and disasters ; and having witnessed one myself in  http://en.wikipedia.org/wiki/2001_Gujarat_earthquake ,it makes me understand the need of a deployment tool like Sahana Eden in a more realisable way. Moreover, I really believe that my work with the Sahana community so far helps me contribute to Sahana and the Eden Project in particular in the coming future.
     31 
     32 
     33 
     34 
     35 
     36 
     37 
     382. Personal Availability
     39 
     40Have you reviewed the timeline for GSoC 2012?
     41 
     42Yes,  I have reviewed the timeline for GSoC 2012.
     43 
     44Do you have any significant conflicts with the listed schedule? If so, please list them here.
     45 
     46No,not really.My semester exams are in the second half of May,2012.However, the coding starts on 21st May according to the timeline.So, I will not be losing any significant time.Moreover, I would be more than happy to start coding before that period so that I will be able to compensate for the few lost days
     47 
     48Will you need to finish your project prior to the end of the GSOC?
     49 
     50No, my project  is planned to be developed along the whole summer.
     51 
     52Are there any significant periods during the summer that you will not be available?
     53 
     54Apart from the conflict listed above, I will be completely available throughout the summer
     55 
     56 
     57 
     58 
     59 
     60 
     61 
     62 
     633. Project Abstract
     64 
     65 
     66The essential requirement for this project is to parse inbound messages , with an initial focus to SMS. The project is specifically aimed at the CERT usecase  where they wish to process responses to deployment notifications. Or in other words , to handle replies to deployment requests. Currently  the message parsing is done in the core code i.e. modules/s3/s3msg.py ,to be particular, in the parse_message() method. The parsing rules will be defined in private/prepopulate which allows for hosting of multiple profile options in the main code.Now,s3parsing.py can import these parsing rules from prepopulate.This also enforces the on-going work in the development of the Profile Layer , in which deployment-specific files are separated from core code.The parsing module utilizes a data model "msg_workflow”  to link the source and the workflow to schedule tasks. Processing of OpenGeoSMS encoded messages is also an important area to work on especially for the existing Android Client, for which it will be of real use. Also to provide robustness and extend the existing code , the pyparsing Parser module can be incorporated or any other parsing generator ; which will be subjective to the parsing needs.
     67 
     68 
     69 
     70 
     71 
     724. Project Plan
     73 
     74Project Deliverable:
     75 
     76The project aims at parsing inbound messages such as SMS from CERT responders after deployment.
    7477It enables the processing of responses to deployment notifications;which is essentially controlled by the module to which the message is routed.
    7578
    76 *'''Project Justification:
    77 '''
    78 *Parsing of inbound messages is a critical utility for a trained volunteer group such as CERT(Community Emergency Response Teams) where communication between various deployments and volunteers play a vital role. As this will be a deployment-specific option, the functionality becomes an important component for Sahana Eden.
    79  
    80 *'''Implementation Plan:
    81 '''
    82 **Keeping the development of Profile Layer in mind and the functionality being a part of deployment-specific options, the rules for parsing are contained in private/prepopulate from where s3parsing.py imports them.
    83 **The module contains a class S3ParsingModel which contains the “msg_workflow” data model (See https://docs.google.com/document/d/1Y9dDCshurrZSw33r-RC_uVQ_Va6_LEZM-2aLcaT2Krc/edit?pli=1) and another class S3Parsing in which the parsing routines are defined which decide the various parsing workflows.
    84 **The current parsing rules implement the functionality in the following manner:
    85 *1The inbound message text is passed as an argument to the parse_message() method in the s3msg.py module.
    86 *2The text is matched with a predefined list of primary and contact keywords after splitting with whitespace as the delimiter.
    87 *3A database query is generated to the concerned database according to the matched keywords.
    88 *4The query retrieves the relevant field values and generates a reply to the inbound message query.
    89 *5Also these parsing rules have been implemented only for modules –  ‘Person’ , ‘Hospital’  and ‘Organisation’.
    90 *6Extending these rules to other modules can be in scope of the project.
    91  
    92 **One of the main issues will be  identifying the messages that belong to a particular  source, so it could have its own processing.Now, that here is handled by the data model which defines a ‘msg_workflow' table in the database which links the Source to the Workflow with any required args.So the essential features of this approach have been listed below:
    93 *1.The Parser workflow table links 'SMS Source X' to 'Workflow Y'.
    94 *2.Now, designing the details of the Workflow Y would be a developer task.
    95 *3.Whereas linking ‘SMS X’ to ‘Workflow Y’ will be a configurable option.
    96 *4.So essentially,the Parser Table links Source to Workflow with any other required args & this acts like a Template for the schduler_task table.
    97 
    98 
    99 **Now, a task process_log() is defined in tasks.py , where the objective of process_log() is to scan through all the messages in msg_log; and process those for parsing which are flagged as unparsed (is_parsed=False).The task is scheduled in zzz_1st_run.py where it is chained to the concerned parsing task(this is achieved by the msg_workflow table, the ‘source_task_id’ field in msg_log will help retrieve the respective parsing workflow_task_id from msg_workflow).
    100 
    101 **Also,this allows for chaining of workflows where a source for a workflow could be another workflow instead of an Incoming source.We can have 2nd-pass Parser workflows which don't start from the Source direct but can plugged as output from a 1st-pass one.
     79Project Justification:
     80 
     81Parsing of inbound messages is a critical utility for a trained volunteer group such as CERT(Community Emergency Response Teams) where communication between various deployments and volunteers play a vital role. As this will be a deployment-specific option, the functionality becomes an important component for Sahana Eden.
     82 
     83Implementation Plan:
     84Keeping the development of Profile Layer in mind and the functionality being a part of deployment-specific options, the rules for parsing are contained in private/prepopulate from where s3parsing.py imports them.
     85The module contains a class S3ParsingModel which contains the “msg_workflow” data model (See https://docs.google.com/document/d/1Y9dDCshurrZSw33r-RC_uVQ_Va6_LEZM-2aLcaT2Krc/edit?pli=1) and another class S3Parsing in which the parsing routines are defined which decide the various parsing workflows.
     86The current parsing rules implement the functionality in the following manner:
     87The inbound message text is passed as an argument to the parse_message() method in the s3msg.py module.
     88The text is matched with a predefined list of primary and contact keywords after splitting with whitespace as the delimiter.
     89A database query is generated to the concerned database according to the matched keywords.
     90The query retrieves the relevant field values and generates a reply to the inbound message query.
     91Also these parsing rules have been implemented only for modules –  ‘Person’ , ‘Hospital’  and ‘Organisation’.
     92Extending these rules to other modules can be in scope of the project.
     93 
     94One of the main issues will be  identifying the messages that belong to a particular  source, so it could have its own processing.Now, that here is handled by the data model which defines a ‘msg_workflow' table in the database which links the Source to the Workflow with any required args.So the essential features of this approach have been listed below:
     95The Parser workflow table links 'SMS Source X' to 'Workflow Y'.
     96Now, designing the details of the Workflow Y would be a developer task.
     97Whereas linking ‘SMS X’ to ‘Workflow Y’ will be a configurable option.
     98So essentially,the Parser Table links Source to Workflow with any other required args & this acts like a Template for the schduler_task table.
     99Now, a task process_log() is defined in tasks.py , where the objective of process_log() is to scan through all the messages in msg_log; and process those for parsing which are flagged as unparsed (is_parsed=False).The task is scheduled in zzz_1st_run.py where it is chained to the concerned parsing task(this is achieved by the msg_workflow table, the ‘source_task_id’ field in msg_log will help retrieve the respective parsing workflow_task_id from msg_workflow).
     100Also,this allows for chaining of workflows where a source for a workflow could be another workflow instead of an Incoming source.We can have 2nd-pass Parser workflows which don't start from the Source direct but can plugged as output from a 1st-pass one.
    102101            Source -> process_log() ->1st pass parser -> detailed Parser ---> Module
    103 **Here,the 1st pass parser is customized per-deployment;and decides which email source goes to a particular workflow (simple msg_workslow link) or decides based on other factors such as keywords to which main workflow the messages should be passed.
    104 **The data model is  integrated with the prepopulate folders (or a sub-folder say private/prepopulate/parsing) which serves as the initial UI.The post-install UI will consist of a CRUD interface admin panel, a simple s3_rest_controller().However, eventually this is planned to be the part of the WebSetup.
    105 **We want to be able to direct the message to the appropriate module to handle the data.This could be done either by launching a real REST request or else simulating one via the API.
     102Here,the 1st pass parser is customized per-deployment;and decides which email source goes to a particular workflow (simple msg_workslow link) or decides based on other factors such as keywords to which main workflow the messages should be passed.
     103The data model is  integrated with the prepopulate folders (or a sub-folder say private/prepopulate/parsing) which serves as the initial UI.The post-install UI will consist of a CRUD interface admin panel, a simple s3_rest_controller().However, eventually this is planned to be the part of the WebSetup.
     104We want to be able to direct the message to the appropriate module to handle the data.This could be done either by launching a real REST request or else simulating one via the API.
    106105             resource = s3mgr.define_resource("module", "resourcename")
    107 **Messages which are routed to a specific resource can be subscribed to by the user.For this purpose,we can use the existing Save Search and Subscription functionality where the user can subscribe to new messages for a specific resource using a resource filter.The msg_log can be made a component for the resources.Now,if it's a component, then when someone opens the resource, messages will be there in a tab.Also, if the message has to be tied to multiple resources, then we can use a relationship (link) table.
    108 **Implementing/extending  the utility for other modules especially the IRS module will be of real use, where enabling to log reports through SMS will be vital, which can also use the OpenGeoSMS encoding standards(LatLon generates a google-maps URL) for integration with our Android Client. A dedicated routine to generate OpenGeoSMS URLs already exists in prepare_opengeosms() in s3msg.py itself. So integration with the parsing routine won’t be difficult. Other modules for which this can be implemented are : ‘Request’  and ’Inventory’.
    109 **Finally the code will be tested on the system and the bugs (if any ;-) ) will be fixed.
    110  
    111  
    112  
    113 *'''Future Options:
    114 '''
    115 **Though the parsing rules will be generic , a few minor tweaks for other processes such as Email and Twitter will have to be performed to maintain its generic nature.
    116 **One of the most valuable functionality that can be added here is to make the SMS communication more interactive. e.g. the text body received does not match any of the expected  keywords , the API dispatches a reply stating the expected format of the message.
    117 **Adapting the parsing rules to cover as wide a base of inbound messages as possible. This will involve making a wider collection of keywords to be searched for every concerned module.Linking different labels  across the DB to module-specific keywords will be really helpful.Also the list of primary keywords to be matched can also be made a deployment-specific option.
    118  
    119  
    120 *'''Relevant Experience:
    121 '''
    122 *I have developed a thorough understanding of the existing parsing routine in the application. Also, I am comfortable using various parsing generators. I have discussed many of the ideas in the proposal with the mentors and rest of the community.
     106Messages which are routed to a specific resource can be subscribed to by the user.For this purpose,we can use the existing Save Search and Subscription functionality where the user can subscribe to new messages for a specific resource using a resource filter.The msg_log can be made a component for the resources.Now,if it's a component, then when someone opens the resource, messages will be there in a tab.Also, if the message has to be tied to multiple resources, then we can use a relationship (link) table.
     107Implementing/extending  the utility for other modules especially the IRS module will be of real use, where enabling to log reports through SMS will be vital, which can also use the OpenGeoSMS encoding standards(LatLon generates a google-maps URL) for integration with our Android Client. A dedicated routine to generate OpenGeoSMS URLs already exists in prepare_opengeosms() in s3msg.py itself. So integration with the parsing routine won’t be difficult. Other modules for which this can be implemented are : ‘Request’  and ’Inventory’.
     108Finally the code will be tested on the system and the bugs (if any ;-) ) will be fixed.
     109 
     110 
     111 
     112Future Options:
     113Though the parsing rules will be generic , a few minor tweaks for other processes such as Email and Twitter will have to be performed to maintain its generic nature.
     114One of the most valuable functionality that can be added here is to make the SMS communication more interactive. e.g. the text body received does not match any of the expected  keywords , the API dispatches a reply stating the expected format of the message.
     115Adapting the parsing rules to cover as wide a base of inbound messages as possible. This will involve making a wider collection of keywords to be searched for every concerned module.Linking different labels  across the DB to module-specific keywords will be really helpful.Also the list of primary keywords to be matched can also be made a deployment-specific option.
     116 
     117 
     118Relevant Experience:
     119 
     120I have developed a thorough understanding of the existing parsing routine in the application. Also, I am comfortable using various parsing generators. I have discussed many of the ideas in the proposal with the mentors and rest of the community.
    123121My experience with the Sahana community has been very enjoyable so far, Sahanathon being one of the highlights where I got the opportunity to demonstrate my ability to work with the code and contribute to Sahana Eden. My notable contributions so far have been listed below:
    124 *1.I solved the bug #1132 in the Trac (http://eden.sahanafoundation.org/ticket/1132) which was merged during the Sahanathon itself. Pull request: https://github.com/flavour/eden/pull/31
    125 *2.Reported and fixed a defect with the update (“Open”) button in the saved searches table.
    126 *3.Made milestones in the project task workflow a deployment-specific option.  (See https://github.com/flavour/eden/pull/35 ).
    127 *4.Fixed email_settings() in the msg controller and required changes in the menu. (See https://github.com/flavour/eden/pull/42 ).
    128  
    129  
    130  
    131  
    132  
    133 === 5. Project Goals and Timeline ===
    134  
    135  
    136  
    137 *'''Work Already Undertaken:
    138 '''
    139 **Currently parsing is implemented by the parse_message() method in the s3msg.py module, though its usage is limited or rather unimplemented as of now.
    140 **Also, the current method is hard-coded and inefficeient to handle different processes.
    141 **A dedicated data model has been developed with consent of the mentors.The msg_workflow has been defined exhaustively in the implementation details and also in the linked gdoc.
    142 **Mechanism to route messages to resources has also been designed and discussed.
    143  
    144 *'''First trimester:
    145 '''
    146 
    147 *'''Due Date -SMART Goal-Measure
    148 '''
    149 *'''(24th April  - 7th May)-
    150 '''*Development of the workflow handling module s3parsing.py starts.
    151 *-
    152 *1.Community bonding period:
    153 *I have been involved with the community for some time now, so won’t take a lot of time :)
    154 *2.Decision to outline the template.
    155  
    156 *'''(8th May – 21st May)-
    157 '''*The msg_workflow data model is developed.
    158 *S3ParsingModel starts to take shape.
    159 *-Code committed locally.
    160  
    161  
    162  
    163  
    164  
    165  
    166 '''Second Trimester:
    167 '''
    168 '''Due Date- SMART Goal -Measure
    169 '''*28th May  -*(won’t be available due to university exams )
    170  
    171 '''4th June-
    172 '''*CERT:Deployment Request SMS Handler development starts ( critical requirement of the project).
    173 *Parsing workflow is developed.
    174 *- SMS response processing starts to take shape.
    175  
    176 '''11th June-
    177 '''*CERT:Deployment Request SMS Handler development continues ( critical requirement of the project).
    178 *-
    179 *1.Code committed locally.
    180 *2.Tested on local system.
    181  
    182 '''17th June-
    183 '''*process_log() method is designed.
    184 *Tweaks in msg_log implemented. 
    185 *-Code committed to trunk.
    186  
    187 '''2nd July -
    188 '''*Parsing workflow is chained to process_log().
    189 *Sources are linked to respective workflows.
    190 *-Code committed to trunk.
    191  
    192 '''8th  July -
    193 '''*Clickatell functionality is developed for eden.
    194 *Clickatell allows for a more robust testing mechanism.
    195 *Commits are altered with mentor feedback and suggested changes.
    196  
    197 *-
    198 *1.Commits so far tested thoroughly.
    199 *2.Bug fixing.
    200 *3.Code committed to trunk.
    201  
    202 *[Mid-Term evaluations :-) ]
    203  
    204  
    205  
    206  
    207  
    208 '''Third Trimester:
    209 '''
    210 '''Due Date-SMART Goal-Measure
    211 '''
    212 '''15th July-
    213 '''*Integration with prepopulate folders.
    214 *Development of post-install UI (CRUD interface admin panel).
    215 *- Code committed locally.
    216  
    217 '''22nd July-
    218 '''*Routing mechanism to resources.
    219 *Save search and subscription implemented for msg_log.
    220 *-Code committed to trunk.
    221  
    222 *'''29th July-
    223 '''*OpenGeoSMS (process_opengeosms() ) routine is tweaked and linked with the respective parsing methods.
    224 *The existing functionality in the Android Client is tested .
    225 *-Code committed to trunk.
    226  
    227 '''5th August-
    228 '''*Integration of the IRS module for incident reporting through SMS.
    229 *The functionality is extended to other modules (if needed).
    230 *Feedback from mentors.
    231 *-Code committed locally.
    232  
    233 '''13th August-
    234 '''*System testing & Bug fixing.
    235 *Final changes to the code are applied.
    236 *-
    237 *1.Project reaches final stage.
    238 *2.Bug fixes
    239 *3.Final Code committed to trunk.
    240  
    241 '''20th August-''' *PENCILS DOWN! -Project Completed. :-)
     122I solved the bug #1132 in the Trac (http://eden.sahanafoundation.org/ticket/1132) which was merged during the Sahanathon itself. Pull request: https://github.com/flavour/eden/pull/31
     123Reported and fixed a defect with the update (“Open”) button in the saved searches table.
     124Made milestones in the project task workflow a deployment-specific option.  (See https://github.com/flavour/eden/pull/35 ).
     125Fixed email_settings() in the msg controller and required changes in the menu. (See https://github.com/flavour/eden/pull/42 ).
     126 
     127 
     128 
     129 
     130 
     1315. Project Goals and Timeline
     132 
     133 
     134 
     135Work Already Undertaken:
     136 
     137Currently parsing is implemented by the parse_message() method in the s3msg.py module, though its usage is limited or rather unimplemented as of now.
     138Also, the current method is hard-coded and inefficeient to handle different processes.
     139A dedicated data model has been developed with consent of the mentors.The msg_workflow has been defined exhaustively in the implementation details and also in the linked gdoc.
     140Mechanism to route messages to resources has also been designed and discussed.
     141 
     142First trimester:
     143
     144
     145Due Date -SMART Goal-Measure
     146(24th April  - 7th May)-
     147Development of the workflow handling module s3parsing.py starts.
     148-
     1491.Community bonding period:
     150I have been involved with the community for some time now, so won’t take a lot of time :)
     1512.Decision to outline the template.
     152 
     153(8th May – 21st May)-
     154The msg_workflow data model is developed.
     155S3ParsingModel starts to take shape.
     156-Code committed locally.
     157 
     158 
     159 
     160 
     161 
     162 
     163Second Trimester:
     164 
     165Due Date- SMART Goal -Measure
     16628th May  -*(won’t be available due to university exams )
     167 
     1684th June-
     169CERT:Deployment Request SMS Handler development starts ( critical requirement of the project).
     170Parsing workflow is developed.
     171- SMS response processing starts to take shape.
     172 
     17311th June-
     174CERT:Deployment Request SMS Handler development continues ( critical requirement of the project).
     175-
     1761.Code committed locally.
     1772.Tested on local system.
     178 
     17917th June-
     180process_log() method is designed.
     181Tweaks in msg_log implemented. 
     182-Code committed to trunk.
     183 
     1842nd July -
     185Parsing workflow is chained to process_log().
     186Sources are linked to respective workflows.
     187-Code committed to trunk.
     188 
     1898th  July -
     190Clickatell functionality is developed for eden.
     191Clickatell allows for a more robust testing mechanism.
     192Commits are altered with mentor feedback and suggested changes.
     193 
     194-
     1951.Commits so far tested thoroughly.
     1962.Bug fixing.
     1973.Code committed to trunk.
     198 
     199[Mid-Term evaluations :-) ]
     200 
     201 
     202 
     203 
     204 
     205Third Trimester:
     206 
     207Due Date-SMART Goal-Measure
     208
     20915th July-
     210Integration with prepopulate folders.
     211Development of post-install UI (CRUD interface admin panel).
     212- Code committed locally.
     213 
     21422nd July-
     215Routing mechanism to resources.
     216Save search and subscription implemented for msg_log.
     217-Code committed to trunk.
     218 
     21929th July-
     220OpenGeoSMS (process_opengeosms() ) routine is tweaked and linked with the respective parsing methods.
     221The existing functionality in the Android Client is tested .
     222-Code committed to trunk.
     223 
     2245th August-
     225Integration of the IRS module for incident reporting through SMS.
     226The functionality is extended to other modules (if needed).
     227Feedback from mentors.
     228-Code committed locally.
     229 
     23013th August-
     231System testing & Bug fixing.
     232Final changes to the code are applied.
     233-
     2341.Project reaches final stage.
     2352.Bug fixes
     2363.Final Code committed to trunk.
     237 
     23820th August- PENCILS DOWN! -Project Completed. :-)