Alejandro Guerrieri wrote:
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.
agreed.
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.
agreed too. But that's "abstract everything" is a bit of a problem while dealing
"only" with HTTP GET variables in smsbox.
If we would have a HTTP abstraction layer towards the application layer, we may
use XML structs to decline driver-specific XML trees that are handled
exclusevely if the moduke "knows" about them, ie.
<xml>
<message>
<to>1234</to>
<from>3333</from>
<parameters>
<... generic parameters ...>
<smpp>
<... some SMPP specific parameters, ie. TLVs ...>
</smpp>
</parameters>
</message>
</xml>
this would be an abstracted way in handling the protocol specific parameters.
Until yet, we had no good approach to do this via the HTTP GET variables, IMO.
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.
hm, how would you assign then the numbering scheme to the TLVs to use?
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.
ok, this does the assignment of the numbering scheme to the SMPP specific
parameters. So far ok. But we want users only to add optional parametes and
their respective length values if they are _NOT_ in the spec. If the parameters
are in the specs, they should be predefined, ie. using the preprocessor-magic we
already use for TLVs.
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.
the usage of a sophisticated "keychain" would make sense here. Where we apply
the smpp-options to a keychain, and everything that is in the chain gets applied.
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.
yep, agree'ing here.
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.
yep, which has performance implications...
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!
any more comments on these from the others?
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
-------------------------------------------------------------------
