Re: Best way to store config or preferences in a multi-platformway.

Discussion in 'Python' started by Ivan Illarionov, May 1, 2008.

  1. On Thu, 01 May 2008 08:30:03 -0500, Nick Craig-Wood wrote:

    > Lance Gamet <> wrote:
    >> This project will store most of its actual data in a shared-database,
    >> but I have a small amount of user specific data that I need to be
    >> stored like configuration or preferences for example, the list of
    >> databases that the program should connect to.
    >>
    >> On Unix this might be a .file, on windows this could be in the
    >> registry, or an ini file or an xml file in ProgramData or AppData or
    >> something.
    >>
    >> Is there a pythony way to store such config data, perhaps there is
    >> already a standard python package for such a purpose?

    >
    > I've found
    >
    > http://docs.python.org/lib/module-ConfigParser.html
    >
    > To be easy to use and built in. It makes human readable / editable .ini
    > - like files.


    IMO .ini-like config files are from the stone age. The modern approach is
    to use YAML (http://www.yaml.org).

    It has a lot of advantages over .ini and xml, YAML syntax was designed to
    be easily mapped to Python data types and is very similar to Python.

    More at http://en.wikipedia.org/wiki/YAML

    As for where to store it, I completely agree with Nick Craig-Wood.

    --
    Ivan
     
    Ivan Illarionov, May 1, 2008
    #1
    1. Advertising

  2. Ivan Illarionov

    Carl Banks Guest

    Re: Best way to store config or preferences in a multi-platform way.

    On May 1, 12:11 pm, Jon Ribbens <> wrote:
    > On 2008-05-01, Ivan Illarionov <> wrote:
    >
    > > IMO .ini-like config files are from the stone age. The modern approach is
    > > to use YAML (http://www.yaml.org).

    >
    > You mean YAML isn't a joke!? It's so ludicrously overcomplicated,
    > and so comprehensively and completely fails to achieve its stated
    > main goal of being "readable by humans", that I had assumed it
    > was an April Fool along the lines of Intercal or brainf***.



    YAML, ISTM, took a simple concept that worked for small,
    straightforward data, and tried to make into a format that could
    anything anywhere, with disastrous results. It's not unlike Perl in
    this regard. It's quite ridiculous.


    My recommendation to the OP would be:

    If you intend to write a GUI that completely sets all the options, use
    XML. You can bet there are some users who would prefer text editing
    options files, and XML, while not the most readable format available,
    at least gives users the option.

    If you don't intend to write a GUI to do that, write a simple text
    file parser (if the options are simple), use ConfigParser, or use a
    Python file that you exec.

    Store the file in $HOME/.appname/config.ext on Unix, $USERDIR/
    ApplicationData/Appname/config.ext on Windows. I don't recommend
    using the Windows registry to store options; use it to modify Windows
    behavior (like file associations) but keep your own program's options
    in your own file.


    Carl Banks
     
    Carl Banks, May 1, 2008
    #2
    1. Advertising

  3. On Thu, 01 May 2008 11:11:29 -0500, Jon Ribbens wrote:

    > On 2008-05-01, Ivan Illarionov <> wrote:
    >> IMO .ini-like config files are from the stone age. The modern approach
    >> is to use YAML (http://www.yaml.org).

    >
    > You mean YAML isn't a joke!? It's so ludicrously overcomplicated, and so
    > comprehensively and completely fails to achieve its stated main goal of
    > being "readable by humans", that I had assumed it was an April Fool
    > along the lines of Intercal or brainf***.
    >
    > I certainly wouldn't recommend it as being suitable for, well, anything
    > at all.
    >
    > Or were you trolling and I missed the joke? ;-)


    No, it isn't. I acually find it usefull and readable. I don't think that
    programmers at Google would use something that is a joke.

    I used XML files before for this purpose and found YAML much easier and
    better suitable for the task.

    Please explain why don't like YANL so much?

    PS. Your reply remind me of early days of Python when Perl programmers
    said exacly the same thing about Python.

    --
    Ivan
     
    Ivan Illarionov, May 1, 2008
    #3
  4. On Thu, 01 May 2008 09:45:28 -0700, Carl Banks wrote:

    > On May 1, 12:11 pm, Jon Ribbens <> wrote:
    >> On 2008-05-01, Ivan Illarionov <> wrote:
    >>
    >> > IMO .ini-like config files are from the stone age. The modern
    >> > approach is to use YAML (http://www.yaml.org).

    >>
    >> You mean YAML isn't a joke!? It's so ludicrously overcomplicated, and
    >> so comprehensively and completely fails to achieve its stated main goal
    >> of being "readable by humans", that I had assumed it was an April Fool
    >> along the lines of Intercal or brainf***.

    >
    >
    > YAML, ISTM, took a simple concept that worked for small, straightforward
    > data, and tried to make into a format that could anything anywhere, with
    > disastrous results. It's not unlike Perl in this regard. It's quite
    > ridiculous.
    >
    >
    > My recommendation to the OP would be:
    >
    > If you intend to write a GUI that completely sets all the options, use
    > XML. You can bet there are some users who would prefer text editing
    > options files, and XML, while not the most readable format available, at
    > least gives users the option.
    >
    > If you don't intend to write a GUI to do that, write a simple text file
    > parser (if the options are simple), use ConfigParser, or use a Python
    > file that you exec.
    >
    > Store the file in $HOME/.appname/config.ext on Unix, $USERDIR/
    > ApplicationData/Appname/config.ext on Windows. I don't recommend using
    > the Windows registry to store options; use it to modify Windows behavior
    > (like file associations) but keep your own program's options in your own
    > file.
    >
    >
    > Carl Banks


    If you don't like YAML, use JSON or something similar -- XML is overkill
    and .INI is too limited.

    --
    Ivan
     
    Ivan Illarionov, May 1, 2008
    #4
  5. Ivan Illarionov

    Carl Banks Guest

    Re: Best way to store config or preferences in a multi-platform way.

    On May 1, 1:30 pm, Ivan Illarionov <> wrote:
    > On Thu, 01 May 2008 09:45:28 -0700, Carl Banks wrote:
    > > On May 1, 12:11 pm, Jon Ribbens <> wrote:
    > >> On 2008-05-01, Ivan Illarionov <> wrote:

    >
    > >> > IMO .ini-like config files are from the stone age. The modern
    > >> > approach is to use YAML (http://www.yaml.org).

    >
    > >> You mean YAML isn't a joke!? It's so ludicrously overcomplicated, and
    > >> so comprehensively and completely fails to achieve its stated main goal
    > >> of being "readable by humans", that I had assumed it was an April Fool
    > >> along the lines of Intercal or brainf***.

    >
    > > YAML, ISTM, took a simple concept that worked for small, straightforward
    > > data, and tried to make into a format that could anything anywhere, with
    > > disastrous results. It's not unlike Perl in this regard. It's quite
    > > ridiculous.

    >
    > > My recommendation to the OP would be:

    >
    > > If you intend to write a GUI that completely sets all the options, use
    > > XML. You can bet there are some users who would prefer text editing
    > > options files, and XML, while not the most readable format available, at
    > > least gives users the option.

    >
    > > If you don't intend to write a GUI to do that, write a simple text file
    > > parser (if the options are simple), use ConfigParser, or use a Python
    > > file that you exec.

    >
    > > Store the file in $HOME/.appname/config.ext on Unix, $USERDIR/
    > > ApplicationData/Appname/config.ext on Windows. I don't recommend using
    > > the Windows registry to store options; use it to modify Windows behavior
    > > (like file associations) but keep your own program's options in your own
    > > file.

    >
    > If you don't like YAML, use JSON or something similar -- XML is overkill
    > and .INI is too limited.



    I don't think you know the OP's requirements enough to know whether
    INI or XML is suitable. You're welcome to suggest alternatives but
    what I suggested is fine.

    As for XML being overkill for anything, I highly disagree. XML is
    suitable for the smallest tasks. These days I use XML for almost all
    my data exchange needs: including conf files. Elementtree makes it
    possible to process XML and pull out some typical data in ten or so
    lines of code. What could possibly be overkill about that?


    Carl Banks
     
    Carl Banks, May 1, 2008
    #5
  6. Ivan Illarionov

    Guest

    Re: Best way to store config or preferences in a multi-platform way.

    Carl Banks <> wrote:
    > On May 1, 12:11 pm, Jon Ribbens <> wrote:
    > > On 2008-05-01, Ivan Illarionov <> wrote:
    > >
    > > > IMO .ini-like config files are from the stone age. The modern approach is
    > > > to use YAML (http://www.yaml.org).

    > >
    > > You mean YAML isn't a joke!? It's so ludicrously overcomplicated,
    > > and so comprehensively and completely fails to achieve its stated
    > > main goal of being "readable by humans", that I had assumed it
    > > was an April Fool along the lines of Intercal or brainf***.

    >
    >
    > YAML, ISTM, took a simple concept that worked for small,
    > straightforward data, and tried to make into a format that could
    > anything anywhere, with disastrous results. It's not unlike Perl in
    > this regard. It's quite ridiculous.
    >
    >
    > My recommendation to the OP would be:
    >
    > If you intend to write a GUI that completely sets all the options, use
    > XML. You can bet there are some users who would prefer text editing
    > options files, and XML, while not the most readable format available,
    > at least gives users the option.
    >

    But XML has human unfriendly syntax, is awkward to type, is difficult
    to read, what's good about it? If there's a GUI between you and the
    XML then OK, but that wasn't where we were was it?

    --
    Chris Green
     
    , May 1, 2008
    #6
  7. On Thu, 01 May 2008 14:13:08 -0500, Jon Ribbens wrote:

    > On 2008-05-01, Ivan Illarionov <> wrote:
    >> I used XML files before for this purpose and found YAML much easier and
    >> better suitable for the task.
    >>
    >> Please explain why don't like YANL so much?

    >
    > Because even the examples in the spec itself are unreadable gibberish.
    > The PyYAML library is over 300kB! These are rather big clues that it's
    > unsuitable for the purpose for which it was designed. It's certainly
    > unsuitable for use as a configuration file format, where it is overkill
    > by several orders of magnitude.
    >
    > !!str &a1 "foo":
    > !!str bar
    > &a2 baz : *a1
    > !<tag:yaml.org,2002:str> foo :
    > !<!bar> baz
    >
    > This is supposed to be human readable?


    Thanx, now I see your point. I didn't mean all the fancy features of
    YAML, but the most basic sintax.

    Compare this:
    <user id="babooey" on="cpu1">
    <firstname>Bob</firstname>
    <lastname>Abooey</lastname>
    <department>adv</department>
    <cell>555-1212</cell>
    <address password="xxxx"></address>
    <address password="xxxx"></address>
    </user>

    and this:
    babooey:
    computer : cpu1
    firstname: Bob
    lastname: Abooey
    cell: 555-1212
    addresses:
    - address:
    password: xxxx
    - address:
    password: xxxx

    I find the latter *much* more readable.

    And the most important thing is that it *maps directly to Python data
    types*, in this case dictionaries and lists:
    {babooey: {computer: cpu1, firstname: Bob, lastname: Abooey, cell: 555,
    1212, addresses: [{address: , password: xxxx},
    {address: , password: xxxx}]}

    I took the example from
    http://www.kuro5hin.org/story/2004/10/29/14225/062
    I haven't use my own example only because I don't have one at hand right
    now. YAML, in its simple form, definetely makes me more productive. I
    wasted too much time with XML in the past and I won't ever use it as a
    serialization or config/settings format again. .INI/ConfigParser is too
    limited and has no standards. I just don't see anything better than YAML
    to do human and Python editable config files and to serialize information
    for later use.

    >> PS. Your reply remind me of early days of Python when Perl programmers
    >> said exacly the same thing about Python.

    >
    > I think I would suffer irony overload if I saw a Perl programmer
    > criticising Python for being hard to read ;-)
     
    Ivan Illarionov, May 1, 2008
    #7
  8. On Thu, 01 May 2008 11:56:20 -0700, Carl Banks wrote:

    > On May 1, 1:30 pm, Ivan Illarionov <> wrote:
    >> On Thu, 01 May 2008 09:45:28 -0700, Carl Banks wrote:
    >> > On May 1, 12:11 pm, Jon Ribbens <> wrote:
    >> >> On 2008-05-01, Ivan Illarionov <> wrote:

    >>
    >> >> > IMO .ini-like config files are from the stone age. The modern
    >> >> > approach is to use YAML (http://www.yaml.org).

    >>
    >> >> You mean YAML isn't a joke!? It's so ludicrously overcomplicated,
    >> >> and so comprehensively and completely fails to achieve its stated
    >> >> main goal of being "readable by humans", that I had assumed it was
    >> >> an April Fool along the lines of Intercal or brainf***.

    >>
    >> > YAML, ISTM, took a simple concept that worked for small,
    >> > straightforward data, and tried to make into a format that could
    >> > anything anywhere, with disastrous results. It's not unlike Perl in
    >> > this regard. It's quite ridiculous.

    >>
    >> > My recommendation to the OP would be:

    >>
    >> > If you intend to write a GUI that completely sets all the options,
    >> > use XML. You can bet there are some users who would prefer text
    >> > editing options files, and XML, while not the most readable format
    >> > available, at least gives users the option.

    >>
    >> > If you don't intend to write a GUI to do that, write a simple text
    >> > file parser (if the options are simple), use ConfigParser, or use a
    >> > Python file that you exec.

    >>
    >> > Store the file in $HOME/.appname/config.ext on Unix, $USERDIR/
    >> > ApplicationData/Appname/config.ext on Windows. I don't recommend
    >> > using the Windows registry to store options; use it to modify Windows
    >> > behavior (like file associations) but keep your own program's options
    >> > in your own file.

    >>
    >> If you don't like YAML, use JSON or something similar -- XML is
    >> overkill and .INI is too limited.

    >
    >
    > I don't think you know the OP's requirements enough to know whether INI
    > or XML is suitable. You're welcome to suggest alternatives but what I
    > suggested is fine.
    >
    > As for XML being overkill for anything, I highly disagree. XML is
    > suitable for the smallest tasks. These days I use XML for almost all my
    > data exchange needs: including conf files. Elementtree makes it
    > possible to process XML and pull out some typical data in ten or so
    > lines of code. What could possibly be overkill about that?
    >
    >
    > Carl Banks


    I used XML for almost everything in the past until I found YAML.
    Elementtree makes it easy but not easy enough. The most powerful thing
    about YAML is that it was designed to map directly to native data types
    in languages like Python (see another my post in this thread for
    example). And this means that simple YAML files will always be easier to
    process in Python than XML or INI. And this in turn means that OP with
    any requirements will have to write less code to read and write his
    config files.

    --
    Ivan
     
    Ivan Illarionov, May 1, 2008
    #8
  9. On Thu, 01 May 2008 23:03:38 +0200, Torsten Bronger wrote:

    > Hallöchen!
    >
    > Ivan Illarionov writes:
    >
    >> [...]
    >>
    >> I took the example from
    >> http://www.kuro5hin.org/story/2004/10/29/14225/062 I haven't use my own
    >> example only because I don't have one at hand right now. YAML, in its
    >> simple form, definetely makes me more productive. I wasted too much
    >> time with XML in the past and I won't ever use it as a serialization or
    >> config/settings format again. .INI/ConfigParser is too limited and has
    >> no standards. I just don't see anything better than YAML to do human
    >> and Python editable config files and to serialize information for later
    >> use.

    >
    > Okay, but serialisation is something completely different. Nobody would
    > use INI files for it.
    >
    > For other things, it simply depends on the use case. For example, I
    > *know* that the configuration files of my pet project will not exceed
    > the dumb section.key=value scheme so anything else would be overkill.
    >
    > Besides, YAML adds another dependency.
    >
    > Tschö,
    > Torsten.


    For me it looks more like an old-school/new-school thing than use-case
    thing. I may be wrong, but I see more and more new projects use things
    like reST and YAML/JSON and it feels like they are gradually replacing
    traditional old-school solutions.

    And I've got very strong impression that YAML is a the future of
    configuration files when Google released their App Engine.

    Of course I may be wrong and it's just my opinion.

    --
    Ivan
     
    Ivan Illarionov, May 1, 2008
    #9
  10. Ivan Illarionov

    Carl Banks Guest

    Re: Best way to store config or preferences in a multi-platform way.

    On May 1, 4:50 pm, Ivan Illarionov <> wrote:
    > On Thu, 01 May 2008 11:56:20 -0700, Carl Banks wrote:
    > > On May 1, 1:30 pm, Ivan Illarionov <> wrote:
    > >> On Thu, 01 May 2008 09:45:28 -0700, Carl Banks wrote:
    > >> > On May 1, 12:11 pm, Jon Ribbens <> wrote:
    > >> >> On 2008-05-01, Ivan Illarionov <> wrote:

    >
    > >> >> > IMO .ini-like config files are from the stone age. The modern
    > >> >> > approach is to use YAML (http://www.yaml.org).

    >
    > >> >> You mean YAML isn't a joke!? It's so ludicrously overcomplicated,
    > >> >> and so comprehensively and completely fails to achieve its stated
    > >> >> main goal of being "readable by humans", that I had assumed it was
    > >> >> an April Fool along the lines of Intercal or brainf***.

    >
    > >> > YAML, ISTM, took a simple concept that worked for small,
    > >> > straightforward data, and tried to make into a format that could
    > >> > anything anywhere, with disastrous results. It's not unlike Perl in
    > >> > this regard. It's quite ridiculous.

    >
    > >> > My recommendation to the OP would be:

    >
    > >> > If you intend to write a GUI that completely sets all the options,
    > >> > use XML. You can bet there are some users who would prefer text
    > >> > editing options files, and XML, while not the most readable format
    > >> > available, at least gives users the option.

    >
    > >> > If you don't intend to write a GUI to do that, write a simple text
    > >> > file parser (if the options are simple), use ConfigParser, or use a
    > >> > Python file that you exec.

    >
    > >> > Store the file in $HOME/.appname/config.ext on Unix, $USERDIR/
    > >> > ApplicationData/Appname/config.ext on Windows. I don't recommend
    > >> > using the Windows registry to store options; use it to modify Windows
    > >> > behavior (like file associations) but keep your own program's options
    > >> > in your own file.

    >
    > >> If you don't like YAML, use JSON or something similar -- XML is
    > >> overkill and .INI is too limited.

    >
    > > I don't think you know the OP's requirements enough to know whether INI
    > > or XML is suitable. You're welcome to suggest alternatives but what I
    > > suggested is fine.

    >
    > > As for XML being overkill for anything, I highly disagree. XML is
    > > suitable for the smallest tasks. These days I use XML for almost all my
    > > data exchange needs: including conf files. Elementtree makes it
    > > possible to process XML and pull out some typical data in ten or so
    > > lines of code. What could possibly be overkill about that?

    >
    > > Carl Banks

    >
    > I used XML for almost everything in the past until I found YAML.
    > Elementtree makes it easy but not easy enough.


    I'm honestly very happy for you that you have found the data transfer
    format that you are happy with, but I'm sorry, that doesn't amount to
    a blanket invalidation of everything you've ever tried and rejected.


    > The most powerful thing
    > about YAML is that it was designed to map directly to native data types
    > in languages like Python (see another my post in this thread for
    > example). And this means that simple YAML files will always be easier to
    > process in Python than XML or INI. And this in turn means that OP with
    > any requirements will have to write less code to read and write his
    > config files.


    I will mention that Python already has, built in, a data transfer
    format that maps directly to Python types: pickle.

    And not only that, it's more readable than YAML.


    I will also add that what you think of as a strength is not always
    thought of as a strength by everyone. In my early days of Python, I
    would use pickle for all kinds of things. I've now pretty much
    switched entirely to XML, because I no longer believe that direct
    correspondance to Python types is a good thing; at least it isn't for
    me. There is a very basic reason for this: whenever I write a pair of
    tools, one to output some XML data, and another further down the chain
    to read it back in, I hardly ever want the data to have the same
    structure in memory in both tools. For me, YAML or pickle would not
    gain me anything; I'd be doing all that reformatting anyway.


    Of course, the OP wasn't talking about data transfer, he was talking
    about a freaking config file. Reading in a config file is a
    ridulously silly thing to try to hyperoptimize. Do you really want
    him to add an extra dependency just to reduce code used by five lines?


    Carl Banks
     
    Carl Banks, May 2, 2008
    #10
  11. On Thu, 01 May 2008 16:32:00 -0700, Carl Banks wrote:

    > On May 1, 4:50 pm, Ivan Illarionov <> wrote:
    >> On Thu, 01 May 2008 11:56:20 -0700, Carl Banks wrote:
    >> > On May 1, 1:30 pm, Ivan Illarionov <> wrote:
    >> >> On Thu, 01 May 2008 09:45:28 -0700, Carl Banks wrote:
    >> >> > On May 1, 12:11 pm, Jon Ribbens <>
    >> >> > wrote:
    >> >> >> On 2008-05-01, Ivan Illarionov <> wrote:

    >>
    >> >> >> > IMO .ini-like config files are from the stone age. The modern
    >> >> >> > approach is to use YAML (http://www.yaml.org).

    >>
    >> >> >> You mean YAML isn't a joke!? It's so ludicrously overcomplicated,
    >> >> >> and so comprehensively and completely fails to achieve its stated
    >> >> >> main goal of being "readable by humans", that I had assumed it
    >> >> >> was an April Fool along the lines of Intercal or brainf***.

    >>
    >> >> > YAML, ISTM, took a simple concept that worked for small,
    >> >> > straightforward data, and tried to make into a format that could
    >> >> > anything anywhere, with disastrous results. It's not unlike Perl
    >> >> > in this regard. It's quite ridiculous.

    >>
    >> >> > My recommendation to the OP would be:

    >>
    >> >> > If you intend to write a GUI that completely sets all the options,
    >> >> > use XML. You can bet there are some users who would prefer text
    >> >> > editing options files, and XML, while not the most readable format
    >> >> > available, at least gives users the option.

    >>
    >> >> > If you don't intend to write a GUI to do that, write a simple text
    >> >> > file parser (if the options are simple), use ConfigParser, or use
    >> >> > a Python file that you exec.

    >>
    >> >> > Store the file in $HOME/.appname/config.ext on Unix, $USERDIR/
    >> >> > ApplicationData/Appname/config.ext on Windows. I don't recommend
    >> >> > using the Windows registry to store options; use it to modify
    >> >> > Windows behavior (like file associations) but keep your own
    >> >> > program's options in your own file.

    >>
    >> >> If you don't like YAML, use JSON or something similar -- XML is
    >> >> overkill and .INI is too limited.

    >>
    >> > I don't think you know the OP's requirements enough to know whether
    >> > INI or XML is suitable. You're welcome to suggest alternatives but
    >> > what I suggested is fine.

    >>
    >> > As for XML being overkill for anything, I highly disagree. XML is
    >> > suitable for the smallest tasks. These days I use XML for almost all
    >> > my data exchange needs: including conf files. Elementtree makes it
    >> > possible to process XML and pull out some typical data in ten or so
    >> > lines of code. What could possibly be overkill about that?

    >>
    >> > Carl Banks

    >>
    >> I used XML for almost everything in the past until I found YAML.
    >> Elementtree makes it easy but not easy enough.

    >
    > I'm honestly very happy for you that you have found the data transfer
    > format that you are happy with, but I'm sorry, that doesn't amount to a
    > blanket invalidation of everything you've ever tried and rejected.
    >
    >
    >> The most powerful thing
    >> about YAML is that it was designed to map directly to native data types
    >> in languages like Python (see another my post in this thread for
    >> example). And this means that simple YAML files will always be easier
    >> to process in Python than XML or INI. And this in turn means that OP
    >> with any requirements will have to write less code to read and write
    >> his config files.

    >
    > I will mention that Python already has, built in, a data transfer format
    > that maps directly to Python types: pickle.
    >
    > And not only that, it's more readable than YAML.
    >
    >
    > I will also add that what you think of as a strength is not always
    > thought of as a strength by everyone. In my early days of Python, I
    > would use pickle for all kinds of things. I've now pretty much switched
    > entirely to XML, because I no longer believe that direct correspondance
    > to Python types is a good thing; at least it isn't for me. There is a
    > very basic reason for this: whenever I write a pair of tools, one to
    > output some XML data, and another further down the chain to read it back
    > in, I hardly ever want the data to have the same structure in memory in
    > both tools. For me, YAML or pickle would not gain me anything; I'd be
    > doing all that reformatting anyway.


    Agree, all depends on programmer's preferences.

    > Of course, the OP wasn't talking about data transfer, he was talking
    > about a freaking config file. Reading in a config file is a ridulously
    > silly thing to try to hyperoptimize. Do you really want him to add an
    > extra dependency just to reduce code used by five lines?
    >
    >
    > Carl Banks


    No, all I want is to give the OP a useful alternative and make him aware
    of the latest trend in the config file formats.

    --
    Ivan
     
    Ivan Illarionov, May 2, 2008
    #11
  12. On Fri, 02 May 2008 01:21:38 +0200, Torsten Bronger wrote:

    > Hallöchen!
    >
    > Ivan Illarionov writes:
    >
    >> [...]
    >>
    >> For me it looks more like an old-school/new-school thing than use-case
    >> thing. I may be wrong, but I see more and more new projects use things
    >> like reST and YAML/JSON and it feels like they are gradually replacing
    >> traditional old-school solutions.
    >>
    >> And I've got very strong impression that YAML is a the future of
    >> configuration files when Google released their App Engine.

    >
    > In contrast to many other areas of software, configuration files needn't
    > be compatible with anything except the user's brain. So even if the
    > rest of the world uses config format X, you can safely stick with config
    > format Y.


    There are several reasons for compatibility:

    1. The user or another developer might want to write GUI front-end to
    configure your app. With standard format this would be easier.

    2. Similar apps might want to have a feature like "import settings" from
    other apps. Traditional config files made this PITA -- and that's why
    this feature is extremely rare.

    3. Bigger applications that include your sofware as one of its components
    may need to automate configuration process and update several config
    files of different smaller apps from one global setting.

    That's precisely why first XML and now YAML became popular for config
    files.

    > I mean, YAML is not really a complex thing, yet it was conceived not
    > before 2001. The reason is that traditional config files do a good job.
    >
    > Tschö,
    > Torsten.


    --
    Ivan
     
    Ivan Illarionov, May 2, 2008
    #12
  13. Ivan Illarionov

    Carl Banks Guest

    Re: Best way to store config or preferences in a multi-platform way.

    On May 1, 7:54 pm, Ivan Illarionov <> wrote:
    > No, all I want is to give the OP a useful alternative


    Fair enough, I can't argue with that.


    Carl Banks
     
    Carl Banks, May 2, 2008
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Max
    Replies:
    2
    Views:
    450
  2. Tarun Mistry

    Best way to store a time?

    Tarun Mistry, Feb 22, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    328
    Karl Seguin [MVP]
    Feb 22, 2006
  3. Alan Silver
    Replies:
    2
    Views:
    352
    Alan Silver
    Jun 5, 2006
  4. CSharpner
    Replies:
    0
    Views:
    1,092
    CSharpner
    Apr 9, 2007
  5. Robert Mark Bram
    Replies:
    0
    Views:
    608
    Robert Mark Bram
    Apr 30, 2007
Loading...

Share This Page