Hi all, any objections or should I commit this patch?
Alex Am 27.01.2014 um 16:22 schrieb Alexander Malysh <[email protected]>: > Hi, > > attached is the announced patch for this functionality. > > Alex > <smpp_resp_meta.patch> > > Am 24.01.2014 um 09:54 schrieb Alexander Malysh <[email protected]>: > >> Hi Stipe, >> >> as usual I'm writing some critic for this patch. I do like this >> functionality BUT I don't like how this >> patch implemented, I don't like this _real don't _real functions because we >> have already to much of them >> and have to start to cleanup it. The second issue is with va_args where it's >> not needed and at this place it's >> not needed. >> >> We have such patch at GTX and I will try to extract this from our sources >> this weekend but in a nutshell it works as follows: >> >> * sent sms with dlr_mask SMSC_CONN_SUCCESS >> * submit_sm >> * submit_sm_resp -> pack TLVs into meta to the sent sms >> * bb_smscconn_(sent|failed) -> generate DLR SMSC_SUCCESS and put meta_data >> from sent sms into resulting DLR >> * smsbox forward it to application >> >> -> no complex va_args , no _real functions needed. This is then really clean. >> >> Btw. The same technic we use for the HTTP , e.g. to pack all CGI params into >> meta_data for the later processing in the application. >> >> Alex >> >> >> Am 21.01.2014 um 19:52 schrieb Stipe Tolj <[email protected]>: >> >>> Hi list, >>> >>> this is a patchset in reference to a request that Paulo Correia made in the >>> users@ mailing list, [Msg-Id: <[email protected]>]. >>> >>> The basic idea is: in SMPP (and other protocols too), we may have meta-data >>> parts (optional TLVs in SMPP) that we get on the "Sent SMS" event, hence in >>> the submit_sm_resp PDU for SMPP. At the moment we don't have a construct to >>> pass this meta-data in the corresponding intermediate DLR SMSC SUCCESS >>> event that we pass to smsbox. >>> >>> The attached patchset allows this at least for optional TLVs coming inside >>> submit_sm_resp. I don't see a clean way to do this for the bind resp PDUs >>> though. >>> >>> The patchset SHOULD be not intrusive, adding only the feature and not >>> changing any standard behavior. Please review and vote for commit. >>> >>> Stipe >>> >>> -- >>> ------------------------------------------------------------------- >>> Kölner Landstrasse 419 >>> 40589 Düsseldorf, NRW, Germany >>> >>> tolj.org system architecture Kannel Software Foundation (KSF) >>> http://www.tolj.org/ http://www.kannel.org/ >>> >>> mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org >>> ------------------------------------------------------------------- >>> <smpp-resp-pdu-optional-tvls.diff> >> >
