Hello I have a kind of a (friendly) disagreement with Manu regarding programming style for linux-dvb. We currently disagree on the best way for ca_zap. This small user land application is in charge of retrieving the pmt info (i.e. an array of char) and create a ca_pmt messages (i.e. another array of char). Unfortunately, the data cannot be directly copied from the first array to the seond array. Some kind of data treatment is required. Currently, ca_zap uses a single loop to read the first array and write the second array with a lots of counters, variables, and some tests to handle the special cases that crept in. Until now, this worked more or less fine. But now, I need to factorize identical ca_desc from es_stream level to program level. (Lest the ca_pmt message is too long to fit in 256 bytes). So ca_zap must now move data before copying them in the second buffer. I've tried to implement this within ca_zap loop fiddling with all the counters and variables but I felt like programming in brainfuck[1]. So far I've only managed an ugly hack to get some TPS channels working, but it's not a solution that will work for other people. So, I was thinking about re-writing ca_zap to use a set of intermediate data structure that would a structured view of the data to be stored in the ca_pmt message. A first loop would read the pmt table and fill the intermediate data structure. A second loop would read (and interpret) the intermediate data structure to fill the set_pmt array of char. IMHO, an intermediate data structure will make the program easier to rad and understand. But it will be bigger. Manu feels that this style of programming using intermediate storage is frowned upon by the dvb community. Even for a user space program. So, my question is, what does the dvb community prefers for ca_zap ? The single do-it-all loop or the 2 steps way ? Thanks for listening to my rant Cheers [1] http://cydathria.com/bf/brainfuck.html
