| [AD] Allegro 4.3 Settings/Conf API |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: alleg-developers@xxxxxxxxxx
- Subject: [AD] Allegro 4.3 Settings/Conf API
- From: Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>
- Date: Tue, 15 Nov 2005 22:22:51 -0700
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=Q9SAg8nfFOo9EpzZPTYCu69lzXAOzSbASTHfrjqLRN5qgIuY+MPeX9vw8iRWXD120oo7Ed1KztP4JQs3bX0BcMmXoDPrSV9uSOCVPmGZony213iz21Zz73ckyCy5fPiWBfmSDBkaV4mnJY0bOPW0wRAszFu96vFvK6mSPJwPIfY=
In the past a system not too far removed from what we have now was suggested,
but should we not allow the system to be "extended"? IE: allow the system
(windows/mac etc) define a storage method for the settings as well as the
user?
So we could allow access to the Windows registry, whatever OSX uses, or even
allow someone to write an XML backend if they so wish?
I actually have a nice config api I wrote for my media admin app, its based on
MAD's MadDB api, and more specifically the SQLite backend, it supports a
registry like heirarchy, but includes the ideas of:
Single Value
Multiple Value (list)
Multiple Choice, Any Value (set of default choices, but doesn't validate)
Multiple Choice, Single Value (set of choices, validates, and only holds one
value)
Multiple Choice, Multiple Value (set of choices, validates, list of values)
Any key can hold one of the above types of data, and be a parent key, which
may contain more keys.
--
Thomas Fjellstrom