| 13 | | |
| 14 | | Age:19 |
| 15 | | |
| 16 | | Education: Currently pursuing B.E.(Bachelor in Engineering) from N.S.I.T, New Delhi. |
| 17 | | |
| 18 | | Country:India |
| 19 | | |
| 20 | | Timezone: GMT +0530 |
| 21 | | |
| 22 | | Linked In Profile: http://in.linkedin.com/pub/ashwyn-sharma/37/bb2/777 |
| 23 | | |
| 24 | | Exposure To Similar Technologies and/or FOSS in general : |
| 25 | | |
| 26 | | 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. |
| 27 | | |
| 28 | | Why would you like to help the Sahana project?: |
| | 11 | Age:19[[BR]] |
| | 12 | |
| | 13 | Education: Currently pursuing B.E.(Bachelor in Engineering) from N.S.I.T, New Delhi.[[BR]] |
| | 14 | |
| | 15 | |
| | 16 | Country:India[[BR]] |
| | 17 | |
| | 18 | |
| | 19 | Timezone: GMT +0530[[BR]] |
| | 20 | |
| | 21 | |
| | 22 | Linked In Profile: http://in.linkedin.com/pub/ashwyn-sharma/37/bb2/777[[BR]] |
| | 23 | |
| | 24 | |
| | 25 | Exposure To Similar Technologies and/or FOSS in general :[[BR]] |
| | 26 | |
| | 27 | |
| | 28 | 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.[[BR]] |
| | 29 | |
| | 30 | |
| | 31 | Why would you like to help the Sahana project?:[[BR]] |
| | 32 | |
| 84 | | 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. |
| 85 | | 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. |
| | 104 | [[BR]] |
| | 105 | |
| | 106 | *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. |
| | 107 | [[BR]] |
| | 108 | *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. |
| | 109 | [[BR]] |
| 87 | | The inbound message text is passed as an argument to the parse_message() method in the s3msg.py module. |
| 88 | | The text is matched with a predefined list of primary and contact keywords after splitting with whitespace as the delimiter. |
| 89 | | A database query is generated to the concerned database according to the matched keywords. |
| 90 | | The query retrieves the relevant field values and generates a reply to the inbound message query. |
| 91 | | Also these parsing rules have been implemented only for modules – ‘Person’ , ‘Hospital’ and ‘Organisation’. |
| | 111 | [[BR]] |
| | 112 | 1.The inbound message text is passed as an argument to the parse_message() method in the s3msg.py module. |
| | 113 | [[BR]] |
| | 114 | 2.The text is matched with a predefined list of primary and contact keywords after splitting with whitespace as the delimiter. |
| | 115 | [[BR]] |
| | 116 | 3.A database query is generated to the concerned database according to the matched keywords. |
| | 117 | [[BR]] |
| | 118 | 4.The query retrieves the relevant field values and generates a reply to the inbound message query. |
| | 119 | [[BR]] |
| | 120 | 5.Also these parsing rules have been implemented only for modules – ‘Person’ , ‘Hospital’ and ‘Organisation’. |
| | 121 | [[BR]] |
| 94 | | 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: |
| 95 | | The Parser workflow table links 'SMS Source X' to 'Workflow Y'. |
| 96 | | Now, designing the details of the Workflow Y would be a developer task. |
| 97 | | Whereas linking ‘SMS X’ to ‘Workflow Y’ will be a configurable option. |
| 98 | | So essentially,the Parser Table links Source to Workflow with any other required args & this acts like a Template for the schduler_task table. |
| 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 | | 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. |
| | 124 | [[BR]] |
| | 125 | [[BR]] |
| | 126 | *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: |
| | 127 | [[BR]] |
| | 128 | 1.The Parser workflow table links 'SMS Source X' to 'Workflow Y'. |
| | 129 | [[BR]] |
| | 130 | 2.Now, designing the details of the Workflow Y would be a developer task. |
| | 131 | [[BR]] |
| | 132 | 3.Whereas linking ‘SMS X’ to ‘Workflow Y’ will be a configurable option. |
| | 133 | [[BR]] |
| | 134 | 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. |
| | 135 | [[BR]] |
| | 136 | |
| | 137 | *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). |
| | 138 | [[BR]] |
| | 139 | *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. |
| 102 | | 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. |
| 103 | | 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. |
| 104 | | 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. |
| | 141 | [[BR]] |
| | 142 | *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. |
| | 143 | [[BR]] |
| | 144 | *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. |
| | 145 | [[BR]] |
| | 146 | *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. |
| 106 | | 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. |
| 107 | | 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’. |
| 108 | | Finally the code will be tested on the system and the bugs (if any ;-) ) will be fixed. |
| 109 | | |
| 110 | | |
| | 148 | [[BR]] |
| | 149 | *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. |
| | 150 | [[BR]] |
| | 151 | *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’. |
| | 152 | [[BR]] |
| | 153 | *Finally the code will be tested on the system and the bugs (if any ;-) ) will be fixed. |
| | 154 | |
| | 155 | |
| | 156 | [[BR]] |
| 113 | | 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. |
| 114 | | 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. |
| 115 | | 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. |
| | 159 | [[BR]] |
| | 160 | *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. |
| | 161 | [[BR]] |
| | 162 | *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. |
| | 163 | [[BR]] |
| | 164 | *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. |
| | 165 | [[BR]] |
| 119 | | |
| 120 | | 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. |
| 121 | | My 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: |
| 122 | | 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 |
| 123 | | Reported and fixed a defect with the update (“Open”) button in the saved searches table. |
| | 169 | [[BR]] |
| | 170 | |
| | 171 | *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. |
| | 172 | [[BR]] |
| | 173 | *My 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: |
| | 174 | [[BR]] |
| | 175 | *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 |
| | 176 | [[BR]] |
| | 177 | *Reported and fixed a defect with the update (“Open”) button in the saved searches table. |
| 136 | | |
| 137 | | 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. |
| 138 | | Also, the current method is hard-coded and inefficeient to handle different processes. |
| 139 | | 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. |
| 140 | | Mechanism to route messages to resources has also been designed and discussed. |
| | 194 | [[BR]] |
| | 195 | |
| | 196 | *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. |
| | 197 | [[BR]] |
| | 198 | *Also, the current method is hard-coded and inefficeient to handle different processes. |
| | 199 | [[BR]] |
| | 200 | *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. |
| | 201 | [[BR]] |
| | 202 | *Mechanism to route messages to resources has also been designed and discussed. |
| | 203 | [[BR]] |
