Re: [PATCH] add support of smsc-id for smpp-tlv group

Alexander Malysh <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Message-ID <[email protected]>
ok, fixed and commited to cvs...

Thanks,
Alex

Am 02.09.2009 um 13:35 schrieb Alejandro Guerrieri:

> Patch looks good (and very welcome!)
>
> +1
>
> PS: There's another typo, "can'be" instead of "can't be" on the  
> comment for "def;ault".
>
> --
> Alejandro Guerrieri
> [email protected]
>
>
>
> On 02/09/2009, at 12:57, Alexander Malysh wrote:
>
>>
>> Am 02.09.2009 um 12:33 schrieb Nikos Balkanas:
>>
>>> Yes, but octstr_split can return a single member list, same way it  
>>> would handle single smsc-ids configured by the user. I have no  
>>> reading problems, and your comment doesn't explain why you have to  
>>> use a list of smscs as your default, just that ';' can be used as  
>>> list seperator since it is not allowed in the smsc-id name.
>>
>> ; used in the middle of default smsc-id because ; can't be there in  
>> the smsc-id configured by user
>> because this is split char and always skipped. Imagine user defines  
>> smsc-id=def;ault What we get after octstr_split(...,  
>> octstr_imm(";"))?
>> Yes we get list with def and ault but never def;ault.
>>
>> Hope this is clear now?
>>
>>>
>>> In terms of efficiency i imagine it would take twice as much time  
>>> to process a list of 2, than a list of one. Plus it doesn't look  
>>> good.
>>
>> see above, this is _not_ a list!
>>
>>>
>>> PS: Can you please fix the Reply-To field in the lists (users 
>>> +devel)? For the past 2 months they don't work right.
>>
>> I fixed Reply-To already. And this is you that make it don't work.  
>> Please use reply to all or just reply and reply to the devel list  
>> instead of private.
>> And please don't use [email protected] address. This is wrong!  
>> Please use [email protected].
>>
>> To clarify: [email protected] and [email protected] set Reply-To to  
>> mailing list. So we can help people avoid reply to person but not  
>> to list.
>>
>>>
>>> BR,
>>> Nikos
>>> ----- Original Message -----
>>> From: Alexander Malysh
>>> To: Development mailing list
>>> Cc: Nikos Balkanas
>>> Sent: Wednesday, September 02, 2009 12:27 PM
>>> Subject: Re: [PATCH] add support of smsc-id for smpp-tlv group
>>>
>>> Hi,
>>>
>>> Am 02.09.2009 um 10:13 schrieb Nikos Balkanas:
>>>
>>>> Hi Alex,
>>>>
>>>> Looks good. Some typos:
>>>>
>>>> Userguide:
>>>>
>>>> string <-> stringr
>>>> ...this TLV valid <-> ...this TLV is valid(twice).
>>>
>>> fixed in my version...
>>>
>>>>
>>>> gw/smsc/smpp_pdu.c: 69
>>>>
>>>> +#define DEFAULT_SMSC_ID "def;ault"
>>>>
>>>> Is this right? Did you mean "default"?
>>>
>>> seems you read only even rows? :)
>>> /* we use ; in the middle because ; is split char in smsc-id and  
>>> can'be in the smsc-id */
>>> #define DEFAULT_SMSC_ID "def;ault"
>>>
>>>
>>>>
>>>> BR,
>>>> Nikos
>>>>
>>>> ----- Original Message ----- From: "Alexander Malysh" <[email protected] 
>>>> >
>>>> To: "Development mailing list" <[email protected]>
>>>> Sent: Wednesday, September 02, 2009 12:58 AM
>>>> Subject: [PATCH] add support of smsc-id for smpp-tlv group
>>>>
>>>>
>>>>> Hi list,
>>>>>
>>>>> seems I was to lazy and didn't implement smsc-id support for  
>>>>> smpp-tlv
>>>>> group :)
>>>>> Attached is patch that corrects this.
>>>>>
>>>>> The rule to look for smpp-tlv group is as follows:
>>>>> 1) by start we put smpp-tlv to smsc-id specific Dict if none  
>>>>> given to
>>>>> default smsc-id.
>>>>>     smsc-id may be a list splitted by ;
>>>>> 2) then if we need tlv by name/tag we look first for specific  
>>>>> smsc-id
>>>>> Dict and if tlv
>>>>>     not found for default smsc-id
>>>>>
>>>>> Comments are welcome.
>>>>>
>>>>> Thanks,
>>>>> Alexander Malysh
>>>>>
>>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------------------
>>>>
>>>>
>>>>>
>>>>
>>>
>>>
>>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.