Re: [gamin] global config file

[Daniel Veillard <veillard redhat com>]

On Thu, Aug 04, 2005 at 11:00:18AM -0400, John McCutchan wrote:
> > > 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 ? 
> 
> Yes, in the case that kernel monitoring is selected, the timeout is for
> when we fall back to poll. I should have been more clear.

  Okay, we will need to augment the documentation section 
    http://www.gnome.org/~veillard/gamin/config.html

> > 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)
> 
> Okay, lets make it lowercase. And in the case when none is selected, we
> won't pass a poll timeout. Sound good?

  I would prefer timeout to be optional. If defined and not "none" then it
overrides the current value, otherwise it is left unchanged (one second by
default).

> >   You didn't express anything about the value for the poll_timeout, is it
> > milliseconds, seconds, or something else ?
> 
> Seconds. Do you think we should go to milliseconds?

  Milliseconds are clearly too short but I could understand going lower
than seconds in the order of the tenth of second, to be lower than the delay
noticeable by an user when doing UI interaction, I'm not 100% sure what's the
best, maybe tenth of second is right.

> >   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
> 
> I assume you mean: fsset civs none 1000

   yeah I noticed that after sending it :-)

> > 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.
> 
> Yes, you are right about the two sets of config statements (fsset vs.
> poll/notify) causing ambiguity. I was delaying looking into that until
> we got the infrastructure in place. I feel that the per filesystem
> preferences should override the path specific ones. But this is a tough
> decision to make.

  It seems to me that the path is more specific so should have priority
over the file system type which is a generic setting. the problem would rather
be as in my example if the specific setting of the user disagree with the
global setting system wide <grin/>. I hate burning policies into libraries.
  
> I really do take your comments seriously. They are valuable and I don't
> want you to get the impression that I am trying to brush you off. I'm
> just arguing for my side :)

   Let's say that one second RTT network delays to the machine where I
process my mail didn't do any good to my mood yesterday :-) . Also explains
an higher amount of typos than average :-\

> kernel monitoring is used. I can think of only one situation, and that
> is where the underlying filesystem is not appropriate for kernel
> monitoring (or poll monitoring). Considering that, I think we should
> deprecate the old config options for the new one. Possibly making a
> policy that if there are any fsset's, the old options are ignored.
> Thoughts?

   I think that path based settings are very important. One need to be able
to exclude a part of a file system, for example just because we know it 
is full of temporary files, think about a spooling system for example.

> > > 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.
> 
> Since choosing kernel monitoring on the wrong filesystem can cause
> serious performance problems, I thought it was a better choice to go
> with the system wide options last. I felt it would be a security concern
> if we the let the user insist on using kernel monitoring on cifs or
> novfs.

   Seems we can't make the policy ourself, it's too complex.
Maybe the system wide config file need 2 sections, one being default
overwritable by the user, and one mandatory which can't be overriden.
This would actually reflects what we see in GConf, so it's probably the
right thing to do.

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/