Re: [PATCH] custom MO Parameters for smsc-http

Me too, second one is far more flexible and clean.
--
Alejandro Guerrieri
[email protected]



On 10/06/2009, at 14:31, Alexander Malysh wrote:

> Hi,
>
> I'm for the second idea, regex rocks ;)
>
> Thanks,
> Alex
>
> Am 10.06.2009 um 12:37 schrieb Franck LAMASUTA:
>
>> It's not so urgent but I could try, it could be interesting...
>>
>> I have 2 ideas so far...
>>
>>
>> First idea
>> ==========
>>
>> I could add 2 new config parameters to define 2 regex:
>> - the first one, to find the start of the foreign id.
>> - the second one, to find the end of the foreign id.
>>
>> For Claro, they could be defined like this:
>> foreign-id-regex-begin = "<transaction-id>"
>> foreign-id-regex-end = "</transaction-id>"
>>
>> For Clickatell, they could be defined like this:
>> foreign-id-regex-begin = "ID: "
>> foreign-id-regex-end = " "
>>
>> For Brunet, they could be defined like this:
>> foreign-id-regex-begin = "MessageId="
>> foreign-id-regex-end = " "
>>
>> In generic_parse_reply(), only in case of success, regex-begin will  
>> be used to find the beginning of the id. Starting from there, regex- 
>> end will be used to find the end of the id. If regex-end can't find  
>> a match, the id will be read until the end of text (body) and an  
>> ending CRLF will be removed.
>> Then, the id will be used to call dlr_add() (like done in  
>> clickatell_parse_reply()).
>>
>>
>> Second idea
>> ===========
>>
>> It's basically the same idea except that only one regex will be used.
>>
>> For Claro, it could be defined like this:
>> foreign-id-regex = "<transaction-id>(.*)</transaction-id>"
>>
>> For Clickatell, it could be defined like this (if an id contains  
>> only digits):
>> foreign-id-regex = "ID: ([0-9]+)"
>>
>> The offsets given by gw_regex_exec() in pmatch[1] could be used to  
>> extract the id.
>> However, it could be more difficult to understand for people who  
>> are not regex experts...
>>
>>
>> Any comment, opinion, suggestion or better idea? :)
>>
>> Franck
>>
>>
>>
>>
>>> From: Alexander Malysh
>>> Sent: Tuesday, June 09, 2009 6:05 PM
>>>
>>>
>>> Am 09.06.2009 um 17:55 schrieb Alejandro Guerrieri:
>>>
>>>> Franck,
>>>>
>>>> The dlr part is inherited from the "kannel" smsc format. In the
>>>> actual implementation there's no way to grab the remote message id
>>>> from a request, and it'd make a lot of sense to be able to do it.
>>>>
>>>> I can try adding it, but don't refrain to do it so yourself if you
>>>> feel the urge (you'll learn a lot about the code in the process!).
>>>
>>> yep, Alex is right here :) and we need more contributors :)
>>>
>>>>
>>>> Opinions?
>>>> --
>>>> Alejandro Guerrieri
>>>> [email protected]
>>>>
>>>>
>>>>
>>>> On 09/06/2009, at 17:47, Franck LAMASUTA wrote:
>>>>
>>>>> Hi Alejandro ,
>>>>>
>>>>> I work with Hervé who posted to this list the 25th of May (Claro
>>>>> http communication).
>>>>> It seems the patch you've done on the generic part could be very
>>>>> useful for us to manage our communications with Claro. It
>>> could be
>>>>> better than a specific implementation for Claro.
>>>>>
>>>>> However, I don't understand how your patch manages a DLR:
>>>>> In generic_receive_sms(), you call dlr_find() (line 1674 of the
>>>>> patched source) to retrieve a previous record stored in the DLR
>>>>> storage.
>>>>> It seems fine except that dlr_add() is never called in
>>>>> generic_parse_reply(), so I guess dlr_find() will always
>>> return NULL.
>>>>> Am I wrong???
>>>>>
>>>>>
>>>>> In fact, when we submit a MT SMS to Claro with this request
>>>>>
>>> http://retail.mds.claro.com.br/MSE/api?profile=xxxx&pwd=xxxx&m
>> ode=assync-delivery&ANUM=3333&BNUM=1234567&TEXT=test
>>>>>
>>>>> we get a HTTP code 200 with this body:
>>>>>
>>>>> <?xml version="1.0" encoding="UTF-8" ?>
>>>>> <mse-response>
>>>>> <status-code>0</status-code>
>>>>> <profile>profleID</profile>
>>>>> <transaction-id>1020606201622668099</transaction-id>
>>>>> </mse-response>
>>>>>
>>>>> So I guess that the transaction-id should be used in
>>>>> generic_parse_reply() to call dlr_add().
>>>>> Unfortunately, the current implementation does not allow
>>> to manage
>>>>> such an id, it only allows to search if the request was
>>> successful
>>>>> or not through the regex.
>>>>>
>>>>>
>>>>> If all my hypothesis are right... :-)
>>>>> I could try to patch generic_parse_reply() to manage also the id
>>>>> through another regex. It will be my first Kannel patch! ;-)
>>>>> If you prefer to do it, no problem, just let me know.
>>>>>
>>>>> If I'm wrong, please clarify how it works.
>>>>>
>>>>> Regards,
>>>>> Franck
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>