RE; HTTP get parameters for optional parameters
I think the only usable way of doing this is to concatenate all the
parameters into 1 HTTP arg
Eg
&binfo=mblox_operator:<5chars>;mblox_tariff:<5chars>;mblox_sessionid:<1-45ch
ars>-Because the way the smsbox and internal messaging is written, this is
the only reasonable way too, with minimal code changes,
- there are already too many functions in a certain file with >20 arguments!
to code it in the fashion of existing code would mean adding further
arguments for each optional parameter!!! -
the decoding/encoding of the arg can be delayed right up to the smpp driver
code ie in the pdu_to_msg() and msg_to_pdu() code.
Like the discussions on a data driven (dynamic) optional
parameters....however I didn't persue it, because (a)the c code (b)i'd
sooner rewrite the whole thing in c++....now if only there was the
time....hehe...{boss}announcement: we have done xxx K msgs this month on the
kannel binds....
{me}...but..the code is ........hard to maintain....{boss} its working, we
got other tasks to do. {me} ...sob hehe!! Anyway much thanks
to this kannel/Kannel group, we wouldn't be here otherwise............
probably should be discussing this in the devel list...............
---- Original Message -----
From: "Stipe Tolj" <[EMAIL PROTECTED]>
To: "Alejandro Guerrieri" <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Thursday, June 08, 2006 1:29 AM
Subject: Re: SMPP 3.4 Optional params
> 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
> -------------------------------------------------------------------
>
