From: Dumas Patrice (dumas@centre-cired.fr)
Date: Fri Oct 25 2002 - 19:11:42 CEST
> SQL was proposed in order to solve multiple concurrency. Otherwise, how
> to solve, if registry is contained in a file?
simple advisory locking should be enough. And all conformant applications
would use it because it would be in the storage layer.
> > It is, but it isn't easy. All the developpers has to agree with a common access
> > scheme and a comon interface with storage layer. It is almost impossible
> > in the unix world, given the inheritance left by old unixes.
>
>
> This is pessimism :-) Developers agreed with SMTP protocol in order to
> write mail-reader, isn't true? They can agree on the configuration API.
> This might me perceived as irriting the very first time, but on the
> final step, the API is useful for the developer itself. A work already done!
There are a lot of legacy or even active applications still in use, with
peculiar configuration scheme and which aren't likely to change (sendmail,
nsswitch, glibc databases (hosts, service....), procmail, fetchmail...).
I must miss a lot of other utilities which would require rewriting config
files and a lot of code, and I am quite sure that the developers won't agree.
> > I don't think a database based on files is less usable than a DBMS or
> > a registry in memory, like for windows. With file locking, journalising,
> > a common format and common access methods text files may be nice configuration
> > repository.
>
> Mmmm ... this is the backaward direction, compared to modern database.
I think that databases are overkill for configuration in most cases, as
in most cases we don't need ACID properties, nor the fast access as
configuration informations are often read only once. Only concurrency is
needed in the base case. When the information is accessed a lot (aliases
database for sendmail, for example), fast read access is needed too.
And real concurrency isn't most important thing, the problem is more with
different applications changing bits without looking at what the other did
nor what the user manually changed. But for that matter, I think that having
an uniform format should be enough. If not, it is because the configuration
utilities are broken (which isn't the case for mulinux, because the user
is warned ;-).
> :-) It lack exactlyy of what we are seaching for.
>
> If you are meaning what I see in the .kde directory, it appears
> as a directory with many subdirectores. The structure is almost a registry,
> but it is for user basis, so no concurrent access.
> But I'm not informed.
The relevant pieces in /etc share the same format, I think.
Pat
---------------------------------------------------------------------
To unsubscribe, e-mail: mulinux-unsubscribe@sunsite.dk
For additional commands, e-mail: mulinux-help@sunsite.dk
This archive was generated by hypermail 2.1.6 : Sat Feb 08 2003 - 15:27:23 CET