Kenneth Aafl?y <lists@xxxxxxxxxxxxxxxxxx> writes: > I'm not sure why you want to bring xml into this picture? Abstracting? Pure laziness. Let me explain... Mpsys protocol objects are specified in XML. Then, the XLST process translates at compile time the specification into C code to generate a parser. This is the same kind of idea that's used with ASN.1 compilers (start from an ASN.1 description to generate BER encoder and decoder). I guess that lex works the same way: start from a grammar and generate a parser. For me, the main advantage is that once the XSLT style-sheet is done, you can quickly and reliably get the complete implementation of a decoder (aka parser in dvb vocabulary). And you don't need to provide unit tests for the parser of *all* the protocol objects. (hence the satisfied laziness part) Only the XLST style-sheet needs to be tested thoroughly. (not an easy task, I grant you) IMHO, the real value is the XML description of the protocol objects. This description could also be used to generate other styles of API if mpsys API style is not suitable for dvb projects (for instance: malloc done inside the API instead of outside, other data structures ...). It could also be used to generate C++ API (or Perl API ;-) ) or API for other languages (ok that would be outside of dvb project) As for the end user, he will never see the XML side of the story as the XML files needs not to be packaged in the binary packages. As for mpsys, it has several parts that should be evaluated separately : - API style (not easy to decide as it's also a matter of taste) - maintenance (requires XLST skills) - evolution (easier: requires basic XML skills) - test coverage (can always be improved) - ... In my opinion, the fact that the code is generated from XML is irrelevant. Only the quality of the generated code must be assessed. The main drawback of code generation is that the amount of generated code can be quite big. In *zap case, if we don't want a full library, we can always trim down the XML description As it is, mpsys would only be a _part_ of a common library for *zap and scan. [interesting proposal deleted, but I lack dvb experience to really comment on the goal] > What do you think? > To radical a goal? No. But it does not preclude (still IMHO) evaluating mpsys qualities and shortcomings. Cheers
