Re: SMPP optional parameters

Alexander Malysh, 


>> The proper attitude according to my opinion should be, that we have a core
>> data structure, but as the lowest common denominator definitely is not
>> good enough, we must add provisions to extend this core in a controlled
>> manner.
>
>In controlled manner? if I look in your patch you propose to define _every_
>TLV in message struct? and later for extra things in emi module? and so
>on...

Yes, what is wrong with that, if they are grouped by function as proposed ?

As I understand it, the Msg structure is the central structure carrying data
around in the system. Why break that good idea because of a non-universal view
of the system ? 
For years records with variants have been around in programming languages and
databases. There is nothing new in that and it could be used here. However, as
RAM is not a scarce resource these days there is no point in defining
variants, but instead use a structure encompassing all data needed. Keep in
perspective, that this is just a question af a few bytes.

My proposal does not break any design. Actually it fits very well into the
current design. Forget the word optional. A parameter is a parameter, but
possibly not used. Whether it is included in the PDU or not is a decision of
the particular module creating the PDU or whatever the final data record may
be.

You could make it academically nicer (and much more prone to errors) by
defining a tree structure of records starting from a single pointer in Msg to
a record with an array of pointers to records for each module.
However, the current linear structure of Msg is much simpler and keeping
things simple is a good thing keeping the program stable.

>Btw. if you want to mantain this patch on your own then at least smpp
>version check is approriate, because smsc with smpp 3.3 version will be
>shocked on TLV.

Thanks for the info.

- Jørgen Thomsen