SMS layouts

[Pawel Kot]

Hi,

In SMS 0.3.x the SMS support is completly brain damaged (I took part in
its creating as well). All SMS related things are in the prone driver. As
there are similiar things to do in the different drivers, the code was
duplicated between the drivers. Even worse: it was duplicated among the
different functions in the same driver.

To solve this issue I intoruced a thing called 'SMS layout' some time ago.
The phone driver only exports some info about the layout of the SMS
(position of different things, whether code some things, etc). It looked
good at the first sight (at least to me). It moved all SMS related things
to the middle layer. But converting all drivers to this concept it came
out that Nokia phones differ that much that it overcomplicated the middle
layer. The differences were: the fields order and their coding schema.

So I thought: "Well, the order in fact belongs to the driver. Why not to
put it there?" The second thing that complicating the code was the issue
whether the field has the fixed length or not. When we don't have to join
all SMS parts in the middle layer we don't care about it.

The proposition is:
 - in the middle laer just code the things into a low level SMS structure
(BCD coding then needed, UDH, UserData, other header fields)
 - in the phone driver join all the things into one (or more) frame
The only thing thet a driver needs to export is how the certain SMS field
should be coded. The fixed/varialble field lenght is not the issue any
more. Also checking if the field is supported by the phone model does not
have to be done.

Any comments? Any weak sides of the idea?

pkot
-- 
mailto:address@hidden :: mailto:address@hidden
http://kt.linuxnews.pl/ :: Kernel Traffic po polsku