Re: [gamin] global config file

[Daniel Veillard <veillard redhat com>]

On Wed, Aug 03, 2005 at 01:45:11PM -0400, John McCutchan wrote:
> On Wed, 2005-08-03 at 13:31 -0400, Daniel Veillard wrote:
> > On Wed, Aug 03, 2005 at 10:11:51AM -0400, John McCutchan wrote:
> > > Yo,
> > > 
> > > I'd like to add support for a global config file. Does /etc/gaminrc make
> > > sense? I'd also like the 'fsset' command. It would look like this:
> > 
> >   It makes sense except I'm wondering about multiple files in a directory
> > but yeah at the current state it sounds fine.
> > 
> 
> I don't understand what you are getting at.

  multiple config files like in /etc . In that case a directory is the way
to go, not needed ATM.

> > > fsset <filesystem type as appears in mtab/fstab>
> > > <"KERNEL"|"POLL"|"NONE"> <unsigned int poll timer>
> > > 
> > > This would set the two preferences on the filesystem type. You can set
> > > that you want KERNEL or POLL or NONE watching. You also set the minimum
> > > time between polls.
> > 
> >   Your description is ambiguous. Can your timer be missing ? If yes what's
> >   the semantic ? If no howdo you make an entry not changing the default.
> >   What happends when multiple conflicting declarations are present ?
> > 
> 
> It's not ambiguous at all.

  for you maybe, for me it is, see below !

> Everything is required. Maybe the line wrap
> caused confusion.

  I said "semantic", i.e. what is the meaning, to me the meaning is ambiguous.

> fsset <fsname> <method> <poll_timeout>
> 
> fsname is "ext3", "nfs", etc..
> method is "KERNEL" or "POLL" or "NONE"
> poll timeout is a number >= 0. 

  what does 
  fsset ext3 KERNEL 100
  means ?  having a kernel handling and a poll timeout is conflicting. Does this
mean 100 is signantly ignored ? Does this mean that 100 is used when resources
are busy and we fall back to poll ? To me this is ambiguous ! Having an 
argument *mandatory* and *silently ignored* is wrong. In that case it should
be optional. To me poll_timeout should be optional if one of the config file
do not want to override the default. Also is has absolutely no meaning for 
"NONE" (why uppercase ? checkall the other config files in your machine for
uppercase words, you will find very little)
  You didn't express anything about the value for the poll_timeout, is it
milliseconds, seconds, or something else ?
  This also conflict with existing config files, *deployed* existing config
  files what happens if there is
    /home poll
in the configuration file (which I expect for example for people using CIFS
because they reported problems otherwise) and 
    fsset ext3 cifs NONE 100
What is the behaviour ? Poll or not ? assuming /home is a cifs fs.
See, to me there is a lot of undefined behaviour, behaviour which may
be expected by users, and behaviour which is hard to check without starting
a debugging session.

  I express reserve on some part of your proposition, I say their meaning is
ambiguous, please at least give me the benefit of the doubt, I have quite a few
line of codes and projects behind me, I'm not just an old fart trying to
stop you, you asked for feedback and I am giving some. Yes the per fstype
configuration information is needed, it should be designed to be clear,
and as much as possible not conflict with existing options already in use,
gam_server being started automatically and transparently we can't just
raise a warning at startup, that would not even reach the user attention.

> If there are conflicting declarations, the last one to be processed is
> the one followed. In gam_conf I parse the user gaminrc first, than the
> system one, so that system administrators can over ride user
> preferences.

  This makes sense, though usually user configuration override systeme wide
so this will nee to be reflected in the documentation because this is 
against common expectations.
   
> > > I'd like to factor the config file reading out of exclude.c into
> > > gam_config 
> > 
> >   You mean a new module ? We would lost history... there is pros and cons.
> 
> Sorry, I've already gone and done it. I just cut the config file reading
> code from gam_excludes.c into gam_conf.c. Now that we've added a new
> config option that doesn't have anything to do with the exclude list it
> makes sense to seperate the config parsing from the subsystems that use
> the config file. As for loss of history, it was 20 lines of obvious code
> I feel like not much was lost. 

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/