You talking about TLV's right? It's a recurring issue, I think. Some operators ask for VARs to add this or that TLV to implement their custom billing module here or there and we are forced to do some terrible patch to comply with "their" specs. I did one once, it's not a "nice job" and creates dependency problems and upgrades issues since then (luckily CVS has been able to keep up with my local patches so far).
I think a more generalised way of dealing with this would be _really_ cool. I also know this kind of parameter it'ss a feature of the SMPP driver and AFAIK Kannel policy it's to "abstract everything", but there should be _some_ way to abstract this kind of SMPP-specific parameters. I'm pasting some ideas Peter Beckham and I discussed sometime ago on this lists (Peter is replying to my mail, so I'm the one with ">" lines ). I think there are at least some starting points. [I know this should probably go to the devel mailing list, but I didn't want to cross-post nor let this thread go without my comments] Here it goes: ============================ From: Peter Beckman Date: Aug 11, 2005 6:04 PM Subject: Re: [Kannel-Devel] Re: [Kannel-Users] Re: Config-based Optional Parameter Functionality To: Alejandro Guerrieri On Sun, 31 Jul 2005, Alejandro Guerrieri wrote:
Peter, It would be great to have such a feature. However, IMHO the configuration parameters are a little cumbersome and could lead to problems in the future. The first thing I'd change is the ability to choose the %X (X = Letter of choice). It would be way to easy for people to overload an already used parameter (%s, %a, you know... nobody reads the docs! ;) ). Furthermore, it could cause problems if future versions of Kannel use that letters for anything else (imagine you start using %M and then Kannel developers choose to use %M for anything else... it would require reconfiguration of the whole system). So, I'd suggest a more generic approach to variable replacement, maybe a two-letter or letter-number, kind of %x1, %x2... %xN, being "x" one unique letter specially reserved for parameter passing and 1, 2, N a number defined on the config.
I'm completely with you on that; users will do things to break it. By moving it outside of what is used, and being able to scale (x1...x35...xN) you can, like you say further down, abstract the whole SMPP structure!
I'd also propose to include an structure for the "dictionary" you've mentioned. It would generalise the ID:Length combination under a generic word. It could even be managed as a special "group". In short my (rather heavily inspired by your insights) dream config would look like this: group = smpp-optional opt-id = 1 parameter-id = billerr_msg parameter-tag = 0x1404 parameter-length = 22 group = smpp-option opt-id = 2 parameter-id = secret_code parameter-tag = 0x1533 parameter-length = 90 So this setup would map to %x1 and %x2.
I love it. We would need to consider whether the "smpp-option" would apply for ALL SMPP connections; if so, if the offset does NOT exist it would be ignored, not warned on; If not, there would need to be a way to tag the SMPP-option to a specific SMSC-id.
IMHO is more generic and more readable. The "parameter-id" could be also get rid of and use some consctruct as ....¶m1=xxxx¶m2=yyyy" to avoid clashing with the system if I'm stupid enough as to set parameter-id to "from", "to" or any other reserved words.
It shouldn't be too hard to come up with a list of reserved words and, before starting, test the config. Then upon any upgrades, list any new reserved words for breaking compatibility. OR even better, force people to use param1..param32..paramN in the URLs, but in the DEBUG log use the human readable parameters. I think that for human-readability, the parameter-id/name should be there; param1 and param2, especially in the DEBUG logs, could become difficult to read and debug.
In fact, this could be used to abstract the whole SMPP structure, but that's another story ;)
*laugh* it could -- that's why I like it. It future-proofs kannel for any SMPP changes, standard or not, without having to recompile. In fact, this method MAY be able to allow people to implement a newer SMPP version without Kannel upgrading the code! ============================ -- Alejandro Guerrieri Magicom http://www.magicom-bcn.net/ LinkedIn: http://www.linkedin.com/in/aguerrieri
