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 execution. Take look to HTML/Javascript. Javascript is doing the 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 (memory).
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.
thanks,
Takashi