[warning: a seemingly bening request that is hard to implement and
followed by long technical discussion]
If I understood correctly, the recommended way to customize fish and
environment variables is not to set them in the init file but just to
use universal variables ("uvars" from now on).
That's fine, but I have an NFS home shared among several computers,
and the uvars are stored per-computer.
Which means I have to customize variables separately on each computer,
which is bad!
Could we have uvars that are shared among all computers that share my home dir?
Sub-issue: do we want 2 scopes - per-host and global - or should all
uvars be shared?
I guess it's quite useful to customize some variable on a per-host
basis, so we probably want both.
Now for the harder issue of implementation.
Using ~/.config/fish/fisd_global in addition to / instead of
~/.config/fish/fisd.* would be easy.
That still leaves the issue of symultaneous logins on several hosts.
Ideally, we would want changes on one host to be seen on other hosts
immediately. Can we do that?
The reason uvars are per-host now is that they are stored in a fishd
daemon running on the same host as fish.
Possible approaches:
* Single daemon:
* Make sure fishd runs at most on one host at the same time.
* Failover ability - launch fishd on one another host if the current
fishd host goes down.
* Have to coordinate a single host through filesystem, without race
conditions.
* Sounds a bit hard to get right (as well as reinventing a wheel).
* GConf already implements this model.
* But GConf brings a lot of dependencies (mainly glib and ORBIT).
* Communicating daemons:
* A daemon on each host, sending notification to other hosts on changes.
* This is crazy. I certainly don't propose to implement it!
* FAM file monitoring daemon implements this model for NFS-mounted files.
* Buf FAM is outdated (dnotify) and controversial (one daemon for
all users).
* Filesystem + notification:
* Store variables directly in file(s) - simple and UNIXish!
* Probably want to have each variable in separate file.
* What about file atomicity and fishd's "barrier" ability? Do we need them?
* With FAM, it should juts work. But see above about FAM issues.
* gamin (FAM's replacement, inotify based) doesn't do network notification.
* inotify with NFS gives notification only for changes caused on
same computer.
* Filesystem + polling.
* Use polling instead.
* For better performance, we should probably touch and poll just
one central "flag file".
If it changed, then we re-read all variables from the actual data file(s).
Remember that uvars don't change frequently!
* Most variables can be polled only when we access them instead of
continually!
* Note also that environment vars have to be polled every time you
poll a big
* Some fish vars like colors now take effect immediatily which is cool.
But taking effect on next prompt or something like that would be
good enough.
* Can still use gamin (or directly inotify?) for better local performance.
* Polling daemon
* fishd on every host that stores data in files and re-reads them
all when the "flag file" if touched.
* Benefit: reduce polling overhead, minimal change to current implementation.
IMHO, the filesystem + polling approach is simplest and best.
But if we want minimal changes, than concentating the polling in fishd is best.
In any case, to reduce corruption risks from simultaneous writing, I
think we should put each variable in a separate file. A single file
with locking could also work, but I'm less sure about it.
--
Beni Cherniavsky <[EMAIL PROTECTED]> (I read email only on weekends)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
