On Thursday 14 September 2000 Steve Lamb wrote:
> On Thu, Sep 14, 2000 at 08:18:52PM +0100, John Sullivan wrote:
>> It provides better data-type support
> How? It is just key/value pairs.
The values can be ints, strings, strings with environment variables,
string lists, binary data and these are all strongly typed. You also
get a sort of "void" type by checking just for the presence of
keys/values.
In an ini file everything is just a string. You can get data out
as either a string or an int, but there's no marking of the type
within the file. The complexity of the app then goes up as it has to
do more validity checking on config data.
>> structured data storage,
> No more than I get on a file system except that it isn't divorced from the
> file system.
A single ini file has a single layer of structure. You have to use a
separate mechanism (subdirectories outside the ini file, or complex
encoding of data within an ini file, which damages editability) if you
need more structure than that.
With the registry the structure is a built-in feature of the config
data space (which you can use or not use as you wish).
>> per-user settings,
> I get that now with the file system. My settings are in /my/ directory...
So all applications have to know how to find your directory. There's
no single standard place under Windows to put per-user files.
>> access-control and more.
> ...which is owned by me.
You are just talking about UNIX here aren't you? Windows is a
different architecture and many of the UNIX idioms just don't
translate like that.
ACLs under Windows (NT) are strictly more powerful facility than the
owner/group/world triples of normal UNIXen. I realise you can apply
them to files too, but you can't apply them to individual profile
sections within an ini file.
>> Using the registry also encourages good data/code separation, and good
>> architectural design by making it clear where different types of data should
>> go.
> Now that is a load of crock if I ever heard one.
Thanks, but it's actually true.
> That is like saying that a dbm file encourages good data/code
> separation. It is a storage type, nothing more.
It's a storage type designed for a particular purpose (holding
configuration data, or meta-data), and it builds in a concept of
system data space, global application data space, per-user data space.
It also has a well-defined concept of which areas belong to a given
application.
This is something that Windows just did not have when everything was
stored in ini files, mostly in C:\Windows, although individual
application policy was generally randomly decided and non-configurable
(how *do* you configure the location of your configuration data?).
>> The registry is no more delicate than .ini files would be, if as much
> Difference is if the registry is hosed I can't boot to edit it.
Depends how hosed. Wax /etc, or win.ini and system.ini on a Win3.1
box, and see how far they get through startup. Now fix it using only
vi.
*Most* "normal" registry problems (similarly to ascii config files)
don't stop the boot process and don't stop you fixing them.
> If an ini file (text file, really) is hosed I can boot with one of,
> oh... 3-4 different options (Linux, BeOS, DOS, & QNX most likely)
> and fix it.
Presuming that option can read your filesystem. (On the several
occasions I've had to repair an NTFS install, I've not had that
luxury. And I've only had to reinstall from CD once, because I
accidentally blatted over the NT partition from UNIX. I had a backup
of all user data.)
Anyway, you can boot a parallel install of NT or Win95 and use that to
repair registry problems that prevent booting.
>> The same goes for most of the other points you mention: there is no
>> inherent difference between storing a given type of data in .ini files
>> and in the registry - it's still the same data with the same
>> limitations.
> No, the registry presents /more/ limitations simply because it says, "It
> must be here and you must use THIS tool to manipulate it."
You can mount custom hives if you must, and the backing file can be
anywhere you like. There are also many different tools you can use on
the registry. I regularly use regedit, regedt32, scanreg, regini and
regdmp. That's just (educated) end-user tools: I can access the
registry from C, VB (if I must), Perl (has a nice hash tie to the
Windows registry!), JScript...
The registry offers guidelines, not rules. It is always down to the
programmer to exercise good judgment, but given the presence of
programmers you don't, I'd rather they put their data in the registry
than in file somewhere - they're more likely to do the right thing
that way.
>> As for multiple profiles: Outlook/MAPI seem to manage multiple
>> profiles per user ID, and all their config is in the registry. There's
>> no reason TB couldn't do it to, it's just an implementation detail.
> No, it is not. I'd love to see you move a different account with just a
> copy command.
Trivial to implement. The copy command might not be the DOS copy
command but it'll do the job. A simple script to do this could be just
2 lines (a REGDMP and a REGINI).
> /THAT/ is the difference. Keep all the relevant data
> /TOGETHER/, not some on the file system, some in a proprietary format database
> and so on.
You'll never have *all* the data together, and that's not what you
want anyway (you probably don't want global config copied across when
you transfer one user account). So again the programmer has to use
good judgement as to which bits of information are likely to need to
be moved together, and which not. In practice this is rarely done, for
either ascii config files or registry data. But because of the
structured nature of the registry you stand a better chance of being
able to extract the chunk you need with regedit.
Really though, what is wanted is a built-in menu option to
import/export a section of configuration (at whatever granularities
make sense) to some more portable (but probably less efficient)
format. At the moment I'm favouring XML for my own work. External
tools (even notepad) shouldn't be necessary at all.
John
--
you gave me something that i could touch in a world where i'd had too much
something i could feel with my broken hands full of lost ideals but soon i'm
returning to you my friend and we'll go where the rivers end in the silver sea
and i'll carry you if you carry me
--
--------------------------------------------------------------
View the TBBETA archive at http://tbbeta.thebat.dutaint.com
To send a message to the list moderation team double-click HERE:
<mailto:[EMAIL PROTECTED]>
To Unsubscribe from TBBETA, double-click HERE:
<mailto:[EMAIL PROTECTED]>
--------------------------------------------------------------
You are subscribed as : [email protected]
