Kenneth Aafløy <lists at kenneth.aafloy.net> 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