Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: channels.conf syntax?



> Personally I don't understand the passion for XML;
> don't you believe that a structure like the one following  (intended as
> an example, not as a proposal) is easier?
>
> [source]
> name=hotbird
> type=SAT
> diseqc_protocol=1.0
> lnb=1
> card=1
>
> [mux]
> name=rai
> source=hotbird
> frequency=11766
> polarization=v
>
>
> [programs]
> name=rai1
> mux=rai
> vpid=160
> apid=80
> .....

Neither do I in general.  However, note that the file format you suggested
above is basically as hard to parse as an XML subset, without any benefits
such as being easier to use regexp's against for scripting updates, etc.

Notice how this just translates into:

<source>
        <name>hotbird</name>
        <type>sat</sat>
        <diseqc_protocol>1.0</diseqc_protocol>
        <lnb>1</lnb>
        <card>1</card>
</source>

<mux>
        <name>rai</name>
        <source>hotbird</source>
        <frequency>11766</frequency>
        <polarization>v</frequency>
</mux>

I'm not going to argue for either really.  From having used both, I find the
microsoft "ini file" style of the first one slightly easier to read, but the
second style much more powerful when you need to nest stuff.  For example,
the above example should probably be better coded as:



<source>
        <name>hotbird</name>
        <type>sat</sat>
        <diseqc_protocol>1.0</diseqc_protocol>
        <lnb>1</lnb>
        <card>1</card>

        <mux>
                <name>rai</name>
                <frequency>11766</frequency>
                <polarization>v</frequency>

                        <program>
                                <name>rai1</name>
                        </program>
                        <program>
                                etc, etc
                        </program>
        </mux>

</source>

Although mentioning XML causes all sorts of tensions, to me there don't
really seem to be more than two ways of doing this anyway - its just the
choice of symbols which changes.  It's a bit like saying C, and PASCAL are
different languages... To my eye they do basically the same thing, its just
the symbols which change (eg BEGIN and END instead of { and }, etc)

The two ways are basically:

- Flat file (Microsoft INI file)
- Hierarchical file (Microsoft registry, XML, emacs style files, etc)

The example above could also be rewritten as

source (Hotbird)
{
        type=sat
        lnb=1

        Mux (rai)
        {
                frequency=11766
                etc

                program (rai1)
                {
                    program detail...
                }
                program (rai2)
                {
                        ...
                {
        }
}

The funny thing is that there are number of people who will happily rail
against the mention of XML, but be quite happy to use the example above,
when in reality it's exactly the same file, but we modify the various field
start and termination characters....  The above should regexp'able from one
form to the other.

However, the XML style file is at least standardised, and you can pick up
any number of code snippets to parse it generically, whereas the other
examples need something writing (not hard).

Ignore the hype.  When someone says "lets use XML", just let that mean:
"hierarchical file format with sensible termination characters on each
field".  Code it up any way you like, but remember that there are a ton of
prewritten tools people can use if you do write it in a certain fashion.
For example if you save all of these in a text file, then most editors and
web browsers will format and highlight the syntax if you use the XML style
file

*****
My opinion would be that you have a hierarchical set of data here, store it
in a hierarchical format...  XML is one variation of this, but pick the
variation which makes sense to you...
*****




-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.



Home | Main Index | Thread Index