Re: [PATCH] Get all available TLV's as Meta-Data

Hi Alex,

patch look good and if no objections from others I will commit it to 
meta-data branch.

As for the message_id. It would be great to have it in meta-data but if 
I think a bit more about it, it will become very messy.

How about defining new field in Msg struct (what you did already) and 
name it like foreign_id. This field will be logged to access log and can 
take message id from any SMSC module?

Thanks,
Alex

Alejandro Guerrieri schrieb:
> Alex,
> 
> Done. Please check the attached patch.
> 
> There's still the issue regarding the "message_id" param on 
> submit_sm_resp / data_sm_resp.
> 
> The new match by tag method voids the option of using the same filtering 
> mechanism mentioned on my previous, mail since it would require a match 
> by name (or inventing a tag
> address for message_id, which is not an option IMHO).
> 
> Since it's not a TLV, does it make sense to add it to meta-data, or 
> maybe exploring other ways to be able to retrieve it? Maybe a special % 
> param or a conf directive like "smsc-message-id-into-meta-data" on the 
> smpp group. Do you have any other ideas about how to achieve this?
> 
> Regards,
> -- 
> Alejandro Guerrieri
> [email protected]
> 
> 
> 
> El 26/11/2008, a las 06:43 a.m., Alexander Malysh escribió:
> 
>> Hi Alex,
>>
>> great!!! :)
>>
>> Could you please change this patch to use dictionary tlv_by_tag 
>> because the name of configured TLV may be different of the one in SMPP 
>> spec. but the tag will be equal. I think it's up to user which name 
>> configured TLV should use.
>>
>> And minor issue: please always make patches from gateway root 
>> directory with cvs diff -Nau.
>>
>> Thanks,
>> Alex
>>
>> Alejandro Guerrieri schrieb:
>>> Hi,
>>> This patch allows meta-data to carry all available TLV's not only the 
>>> User-Defined.
>>> All TLV's defined on smpp_pdu.def were "hijacked" by the main pdu 
>>> structure, so they never reached the tlv dictionary. What this patch 
>>> does is to check for defined TLV's on the smpp-tlv group and copy 
>>> them to the tlv dictionary. Those TLV's are then available on the 
>>> meta-data parameter.
>>> It only copies the TLV's explicitly defined, otherwise the meta-data 
>>> parameter would be unnecessary cluttered with all available TLV's.
>>> This solves the "receipted_message_id" issue with deliver_sm (to name 
>>> one), but does _not_ solve the "message_id" param on 
>>> submit/deliver/data_sm_response, since message_id is not a TLV.
>>> For that parameter I could add a call for meta_data_set_value to 
>>> inject it into the meta data (already tried and works), but then it 
>>> would be always available.
>>> To avoid this, I could use the same filtering mechanism as with the 
>>> TLV's, but that would mean defining a dummy tag address, since this 
>>> is not a TLV so it doesn't have a documented address. I could filter 
>>> using tag_by_name, so the address wouldn't matter anyways, but it's 
>>> somewhat ugly imho.
>>> Ideas? Opinions?
>>> Regards,
>>> -- 
>>> Alejandro Guerrieri
>>> [email protected]
>>
>>
>