Re: [Evolution-hackers] Local calendars with custom files
On Mon, 2011-02-07 at 09:46 -0500, Matthew Barnes wrote: > On Mon, 2011-02-07 at 09:50 +0100, Milan Crha wrote: > > And that's what is wrong with it. I do not know the polling interval, > > chosen by gio developers, but I prefer to be able to set the polling > > time myself, for fine-tuning. Not talking about unnecessary network > > traffic for those (rather rare?) cases. > > What network traffic? Evolution only lets you choose a file on the > local file system. I thought of something like /mnt/samba/... > > All three options are used for different purposes and use cases, to be > > able to configure one writer and multiple readers, for example, because > > there is done no file-locking and such. > > I'm not suggesting dropping the "force read-only" option. > > Users of these custom files expect the calendar data as shown through > Evolution to be kept up-to-date with the file contents and my guess is > they don't care how. They should never be looking at stale data. > > A file monitor is clearly the best mechanism for knowing when to refresh > a local calendar, and if the file never changes then the only resource > lost in monitoring the file is one file descriptor. Big deal. I see no > need to burden the user with this choice. Maybe. I let it up to you. I thought those options might be useful when I was implementing those bits into evolution. If you think it's overcomplicated, then feel free to drop it and use the best default, which is surely the file monitoring. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Local calendars with custom files
On Mon, 2011-02-07 at 09:50 +0100, Milan Crha wrote: > And that's what is wrong with it. I do not know the polling interval, > chosen by gio developers, but I prefer to be able to set the polling > time myself, for fine-tuning. Not talking about unnecessary network > traffic for those (rather rare?) cases. What network traffic? Evolution only lets you choose a file on the local file system. > All three options are used for different purposes and use cases, to be > able to configure one writer and multiple readers, for example, because > there is done no file-locking and such. I'm not suggesting dropping the "force read-only" option. Users of these custom files expect the calendar data as shown through Evolution to be kept up-to-date with the file contents and my guess is they don't care how. They should never be looking at stale data. A file monitor is clearly the best mechanism for knowing when to refresh a local calendar, and if the file never changes then the only resource lost in monitoring the file is one file descriptor. Big deal. I see no need to burden the user with this choice. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Local calendars with custom files
On Sun, 2011-02-06 at 09:00 -0500, Matthew Barnes wrote: > My question is can we do away with these refresh choices and just use > a GFileMonitor always? Hi, please keep them there. The "On Open" is meant for static files, and means "Only On Open and never again". > I can't come up with any use cases where you would NOT want to use a > file monitor. If the operating system doesn't support file > monitoring, or if the file is on a file system that doesn't support > file monitoring, GIO falls back to polling the file at regular > intervals anyway. And that's what is wrong with it. I do not know the polling interval, chosen by gio developers, but I prefer to be able to set the polling time myself, for fine-tuning. Not talking about unnecessary network traffic for those (rather rare?) cases. All three options are used for different purposes and use cases, to be able to configure one writer and multiple readers, for example, because there is done no file-locking and such. What is a gain in removing these options, simpler UI? Then pack it under "Advanced Options" collapseable section, together with readonly access and maybe others, based on your wish. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
