development model discussion: data storage
mlw
how to store data.
In my view, I don't see any advantage to not using a file system where it is
appropriate. While CVS could do something better with its file format, and
do a better job at understanding binary formats, I think its use of the
file system for repositories is perfectly appropriate.
A centralized "registry" vs the UNIX "/etc" directory. Is there any real
advantage to a registry over a directory?
I can't think of a single "real" feature (by real, I mean feature or
capability that can not be accomplished by a an appropriate methodology).
Obviously, this is a subjective discussion. You "can" put every row in a
database in its own file in a directory that represents a table, right?
/myvol/databases/mydatabase/mytable/row.dat.
You could go even further
/myvol/databases/mydatabase/mytable/rowname/data.dat
It is obviously a balance and subjective. Opinions?
Hadron Quark
The benefits using a pre-developed, transaction based database for
storing and retrieving information can bring you. Sure, there are flat
file based "databases" such as BTrieve (or whatever they are called
now), but nearly always they have some half assed SQL based transaction
handling interface tacked on. Why reinvent the wheel.
With a single (or multiple) centralised "registries" (or big files owned
by the rdbms), there can be many optimizations performed in record
layout, indexing etc which would not be possibly if all data was spread
as seperate entities in the manner you propose.
yttrx
And now you're a plagiariser. Very nice. You just never stop, do
you hadrin.
-----yttrx
amicus_curious
"mlw" <m...@nospamnoway.zz> wrote in message
news:peydnf0ZptXZUkDY...@comcast.com...
>
> A centralized "registry" vs the UNIX "/etc" directory. Is there any real
> advantage to a registry over a directory?
>
all in one sock and that is hidden from view. Another, I think, is the
existence of the registry access APIs that simplify code needed to access
program data, i.e. you don't have to open flat files and parse their
contents with code.
Peter Köhlmann
And again billwg (LOL-boy) shows that he has no clue about linux at all
Hint, you dumb wintroll: There are standard access methods for the config
files in linux as well
Now, would you please tell us the excellent and many ways you can put in
comments into the registry to explain each setting in clear, well readable
text at the point where it actually is needed?
God, are you stupid. And ignorant
You are a windows user. And it shows
--
Real programmers don't comment their code. It was hard to write,
it should be hard to understand.
Hadron Quark
plagiariser? What are you talking about t-rex? Has someone almost
stepped on you again?
Hadron Quark
There would be an api to talk to the hierarchical file system
too. Google up btrieve. Its how flat filesystem storage works. You dont
access it by hand.
Hadron Quark
You are misunderstanding the use of the word registry in thie case. mlm
coined it but what he means is the database repositories.
--
yttrx
Peter Köhlmann
I misunderstand exactly nothing when billwg talks about the registry
And I don't vcare at all about mlw and his "database repositories"
I answered Bill Weisgerber, you cretinous lump of horse manure
And now go playing in the street, "true linux advocate" and "kernel hacker"
Hadron Quark. You are simply a worthless oxygen thief
--
Warning: You have moved the mouse.
Windows will reboot now to make the change permanent
amicus_curious
"Hadron Quark" <hadro...@gmail.com> wrote in message
news:87bqjmh...@gmail.com...
At the risk of inciting the Linux application geniuses that abound here, my
post was in regard to accessing the Windows registry and retrieving some
configuration for my application with something like :
RegistryKey MyKey =
Registry.LocalMachine.CreateSubKey("Software\\MyCompany\\MyApplicationSection\\"
);
string MySetting = MyKey.GetValue("MySetting ", "").ToString();
My understanding of /etc is that it is the directory that contains a bunch
of flat files that pertain to the system in general and also to individual
applications that use it as a string stash for application relevant data.
If I need some item from one of those files, how do I get it? My first
thought is that I open the flat file and parse its contents in some way to
get to the element I need a value setting for. That is how I remember it
and also the way that Windows used to access .ini files. You could and
probably would create some class to encapsulate an INI file or an /etc file,
of course, but is it built into the system as it is with Windows? In any
case there is no plethora of files to keep track of.
tha...@tux.glaci.remove-this.com
>
> The major benefit is a reduction in file clutter, since the registry has it
> all in one sock and that is hidden from view. Another, I think, is the
> existence of the registry access APIs that simplify code needed to access
> program data, i.e. you don't have to open flat files and parse their
> contents with code.
The registry is the single worst design decision that Microsoft ever
came up with. It is a brittle, overly centralized, single point of
failure that hampers the easy portability of user specific settings.
Thad
Peter Köhlmann
Tell us more about your complete lack of knowledge about the workings of
linux, LOL-boy
--
I refuse to have a battle of wits with an unarmed person.
Linonut
> amicus_curious wrote:
>
>> My understanding of /etc is that it is the directory that contains a bunch
>> of flat files that pertain to the system in general and also to individual
>> applications that use it as a string stash for application relevant data.
>> If I need some item from one of those files, how do I get it? My first
>> thought is that I open the flat file and parse its contents in some way to
>> get to the element I need a value setting for. That is how I remember it
>> and also the way that Windows used to access .ini files. You could and
>> probably would create some class to encapsulate an INI file or an /etc
>> file,
>> of course, but is it built into the system as it is with Windows? In any
>> case there is no plethora of files to keep track of.
>
> Tell us more about your complete lack of knowledge about the workings of
> linux, LOL-boy
The boy needs to read about the POSIX configuration-access functions.
Maybe he should spend a good couple weeks with "Advanced Programming in
the UNIX Environment".
--
[ X ] Check here to always trust content from Linonut.
DFS
> plagiariser? What are you talking about t-rex? Has someone almost
> stepped on you again?
Occupational hazard when you're a professional shrimp.
DFS
You're right on with this one: it's a confusing monstrosity of arcana. Not
sure if it's actually brittle, though; in 12 years of Windows use,
installing/uninstalling hundreds of apps, I've never seen an error message
reporting "corrupt registry". Now, I've had to edit the Registry to fix
other problems - how that differs I'm not sure :)
These guys have been trying to simplify/clone it for Linux
http://elektra.g4ii.com/Main_Page
Kelsey Bjarnason
Whereas with a little thought it could have been an excellent concept.
Example: make it a proper database. Aside from the performance increase
over the mess it is now, you could (if it were properly designed) do
things such as query on what settings pertain to, say, MS Word and get
*every* setting pertaining to MS Word.
Exports to flat-file, secondary DB and so forth would be relatively easy,
as would be re-importing.
Updates could be atomic; either every setting for the app worked
correctly, or none do - and a reinstall would simply need to re-apply the
registry entries, not the entire app.
Versioning could be implemented relatively easily; thus the whole "restore
point" notion could be little more than selecting which version of the DB
state to use - on a per-app or system-wide basis - with an "accept" option
to confirm that yes, the settings are working.
Not to mention that, again with proper design, it should be trivial to
determine which entries no longer belong because the apps/files/versions
they apply to no longer exist; purging would become both fast and trivial,
keeping things pristine.
While perhaps this is a less than optimal notion, one could even add a
comment field to every single entry - and even those could be versioned.
Ponder a registry editor which showed you not only the settings, but a
description of what they mean, the original values, the current values,
even a history of changes - and comments on why the changes were made.
On the other hand, Linux's approach of using plain text files accomplishes
most of this, and with the use of svn or cvs, etc, you can even get the
versioning and history.
The existing registry has no justification for existing at all; it is as
you say brittle and performance-degrading for no good reason.
--
Do not contact me at kbjar...@ncoldns.com