[alsa-devel] [PATCH] ascenario: Add scenario support to alsa-lib
tiwai at suse.de
Wed Oct 7 11:55:48 CEST 2009
At Wed, 7 Oct 2009 11:47:19 +0200 (CEST),
Jaroslav Kysela wrote:
> On Wed, 7 Oct 2009, Takashi Iwai wrote:
> >> But regarding goto, I'm really stuck. We can add some block control:
> >> BEGIN="" .. END="" (looks like a goto anyway)
> > Hm, still not much improvement, indeed.
> >> Or skip some lines:
> >> SKIPLINES="3"
> > Oh, no! I don't want to debug a DSP assembly :)
> >> But these solutions do not bring much readability. Another possibility
> >> (compromise) is to use a goto command to skip all lines to next label to
> >> reduce usage of named labels (which is not a big fun at least in
> >> init/default file):
> >> GOTO=""
> >> ....
> >> LABEL=""
> >> It works without any code change in current parser.
> > I'm afraid that udev config is way too simple for the conditionals.
> There are plenty conditionals in udev configuration files. That was main
> reason to use this syntax for alsactl.
> > And we do need conditionals to handle many cases. XML can do better
> > for such a purpose, but moving to XML now is another question...
> Really better?
I don't know exactly, honestly. I don't like XML much either :)
> XML is good for static data but not for non-linear
> non-linear stuff and eventually modifies XML at runtime. We have similar
> situation in alsa-lib. The syntax structure is changed at runtime
> depending on external data. But it requires some system resources
> Things why I chose udev-like syntax:
> - well known "key operator value" syntax
> - very easy to parse
> - parser reads and executes code directly without storing the source
> or portions to memory (really small memory usage)
> - normal conditions are really small in syntax files
But fairly hard to read. Do you remember the very trivial syntax
errors we hadn't noticed over months? It was just because of the bad
readability of this config file.
> If only the goto command is major drawback, I can live with it.
> We need to take account the useability and the implementation complexity.
> I think a compromise is essential.
I don't care much right now about alsactl init stuff, supposing that
we won't add likely any bigger stuff. But I'm against to deploy it
over other areas, especially for new ones.
More information about the Alsa-devel