Dominique Dumont wrote: > Manu Abraham <manu@xxxxxxxxxxx> writes: > > >>>It depends on where the development is going. IMHO ca_zap should >>>stay a small tool similar to szap, so if it works now with libsi, >>>why would you want to change that? >> >>The question that was raised by Dominique was that he would like to >>to replace (libsi) the factored out code from ca_zap, with mpsys.. > > > As Johanness stated, it depends on where you want to push libsi > (eventually): > - either a full SI parser. In this case, it would be a shame not to Since Johannes said that the small applications in dvb-apps should not depend upon an external library, It makes sense to have a full blown SI parse ? Anyway, it is open to suggestions and or discussions.. I am open on that one.. My curent objective of libsi is to factor out code from ca_zap, such that ca_zap's readability/maintainability is better as you commented earlier .. > consider mpsys or the code generation approach that was developed > there. An important aspect is that for a small part having library to do that small part can be considered a bloat, another part is that again for CA PMT object formation , one has to parse again, which again defeats that purpose.. Then with all that the advantage what mpsys would be doing would be PAT/PMT parsing.. Even if you require a bit more you don't need a full blown generic parser, where in which you can have a well tailored small set of routines to do the very same job. Another aspect what we should look at is whether we want to have everything implemented in one shot, or implement as required. I would always opt for the latter since this style would be better for having it tailored to the requirements rather than a complete generic library.. That is what i meant .. > - Just a PAT/PMT parser and CA_SET_PMT encoder. In this case, manual > coding is fine. But the libsi name may be misleading. > This is anyway Service Information.. And hence i put in that one.. I think it is SI itself i am parsing rather than an entire TS. But i don't object to any other names either, if they fit better. > I guess that the question will arise againg when you'll want to > implement the MMI handling as they many protocol objects to encode or > decode. > But again that would not be going into libsi, but liben50221 as MMI functions are part of the EN50221 specification. > >>>OTOH if you (or someone else) wants to write a larger dvb library, >>>then why reimplement all of SI parsing if there are exisiting libs >>>for it? > > > Furthermore, for other protocol, why use manual coding when mpsys > author developed a techno that enable you to generate the decoder > routines ? > Maybe it would be looking like trying to hit a fly with a hammer.. ? Manu
