To support third-party tools it would be great to be able to convert lircd.conf files and perhaps also lircrc ones to XML - parsing these is otherwise hard.
For lircd.conf files, probably just a new option to lirc-lsremotes.
If I understand you correctly, you are talking about an
"embedding" of the current lircd.conf in XML, rite?
Parsing lircd.conf is indeed a PITA. There are two reasons for this:
semantic and syntactic. The semantic problem: it was never clear exactly the
rules the lircd.conf has to obey: what is the character set used?
(alternatively, how do you say what character set you are using?), what
are the allowed characters allowed in names?, in partucular, is
whitespace allowed in names or not? The syntactic problem: Only Lirc
understands the Lirc rendering engine, and it is really its parameters
that the lircd.conf encode. (IrScrutinizer/Jirc can parse these, BUT
for this it contains parts of Lirc (converted to Java).)
Your suggestion would definitely solve the semantic problem, but not
the syntactic problem. I doubt that it is worth if.
For "Lirc 2.0" I would suggest dumping the Lirc rendering engine, and
using Girr (http://www.harctoolbox.org/Girr.html), with raw data
compulsory, as data base format (alternatively exchange format,
internally possibly a more efficient (sql?) format).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A small step, agreed. But easy to implement, and useful for e. g., third-party people. I looked into the mess those trying to code gnome-lirc-properties has been running to... for them it would have been helpful, for sure.
name cannot contain spaces, as defined in lircd.conf(5).
I agree about the semantic problem. I just want to make this database available to others, which basically seems like a good idea, despite these problems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After some nights sleep I think you have a point. But from a tools perspective, the timing information is not really useful and could be omitted. The important thing is that a config file has a name, timing info or not, possibly (LIRCCODE) a required driver, and a list of button names. At this level the semantics are clear, and that's about what's needed.
If we want to export the timing info we need something else. Converting a non-raw file to a raw format is doable, and that data should be possible to export (?).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As you know, there are really two very different usecases, timing info and "lirccode". It is in general neither necessary nor possible (without additional information) to transfer "lirccode signals" to signals with timing. In my previos post, I covered only the timing case, since that is my main interest. The other case can also be easily covered with the Girr format, see the enclosed file.
The Girr format is there, documented, and has a good schema (xsd), and fills all the needs. Are you intending to reinvent the wheel?
But from a tools perspective, the timing information is not really useful and could be omitted.
I cannot make sense of that statement.
The important thing is that a config file has a name, timing info or not, possibly (LIRCCODE) a required driver, and a list of button names.
I'm perfectly happy with the girr format, and have no intention at all to re-invent the wheel.
Here is really two usecases. One is third-party projecs which tries to enhance configuration tools. This is hard, since the formats are like they are. If we could export the basic parts l in some XML format it would make things easier. It's in this context the timing actually isn't required and could (should) be omitted. Look at the bash (!) "parsing" in lirc-config-tool or the gnome-lirc-properties madness.
The other would be to make the timing data in all these config files available in some other format to be useful to others. Girr would be perfectly OK, but I'm not the person to write that filter. What I could do is to export the config file timing data is (another) XML format, which could then be input to next step. I don't see this XML format as an "official" one, it's more like a implementation, intermediary step. This is more vague ideas, and I will not start this part unless someone wants the data.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If I understand you correctly, you are talking about an
"embedding" of the current lircd.conf in XML, rite?
Parsing lircd.conf is indeed a PITA. There are two reasons for this:
semantic and syntactic. The semantic problem: it was never clear exactly the
rules the lircd.conf has to obey: what is the character set used?
(alternatively, how do you say what character set you are using?), what
are the allowed characters allowed in names?, in partucular, is
whitespace allowed in names or not? The syntactic problem: Only Lirc
understands the Lirc rendering engine, and it is really its parameters
that the lircd.conf encode. (IrScrutinizer/Jirc can parse these, BUT
for this it contains parts of Lirc (converted to Java).)
Your suggestion would definitely solve the semantic problem, but not
the syntactic problem. I doubt that it is worth if.
For "Lirc 2.0" I would suggest dumping the Lirc rendering engine, and
using Girr (http://www.harctoolbox.org/Girr.html), with raw data
compulsory, as data base format (alternatively exchange format,
internally possibly a more efficient (sql?) format).
A small step, agreed. But easy to implement, and useful for e. g., third-party people. I looked into the mess those trying to code gnome-lirc-properties has been running to... for them it would have been helpful, for sure.
name cannot contain spaces, as defined in lircd.conf(5).
I agree about the semantic problem. I just want to make this database available to others, which basically seems like a good idea, despite these problems.
After some nights sleep I think you have a point. But from a tools perspective, the timing information is not really useful and could be omitted. The important thing is that a config file has a name, timing info or not, possibly (LIRCCODE) a required driver, and a list of button names. At this level the semantics are clear, and that's about what's needed.
If we want to export the timing info we need something else. Converting a non-raw file to a raw format is doable, and that data should be possible to export (?).
As you know, there are really two very different usecases, timing info and "lirccode". It is in general neither necessary nor possible (without additional information) to transfer "lirccode signals" to signals with timing. In my previos post, I covered only the timing case, since that is my main interest. The other case can also be easily covered with the Girr format, see the enclosed file.
The Girr format is there, documented, and has a good schema (xsd), and fills all the needs. Are you intending to reinvent the wheel?
I cannot make sense of that statement.
Being too file system oriented here,
I'm perfectly happy with the girr format, and have no intention at all to re-invent the wheel.
Here is really two usecases. One is third-party projecs which tries to enhance configuration tools. This is hard, since the formats are like they are. If we could export the basic parts l in some XML format it would make things easier. It's in this context the timing actually isn't required and could (should) be omitted. Look at the bash (!) "parsing" in lirc-config-tool or the gnome-lirc-properties madness.
The other would be to make the timing data in all these config files available in some other format to be useful to others. Girr would be perfectly OK, but I'm not the person to write that filter. What I could do is to export the config file timing data is (another) XML format, which could then be input to next step. I don't see this XML format as an "official" one, it's more like a implementation, intermediary step. This is more vague ideas, and I will not start this part unless someone wants the data.
Please have a look at this issue (and possibly even leave feedback...).
PS. Happy new year!!
This is not a feature we intend to implement. Sure, a new format might be great but XML comes with many of its own problems. That's not the answer.