One way to get what you want is to simply use the same fishd socket on
all machines. Can UNIX sockets be shared through e.g. NFS file shares?
If so, your problem is already solved, just set the FISHD_SOCKET_DIR
variable to point to the same place everywhere and it's rock and roll.
If Unix sockets can't be shared, it would be possible to instead use a
tcp socket. The additional code should be fairly minimal, I guess.
Axel
On Jan 22, 2008 6:20 PM, Beni Cherniavsky <[EMAIL PROTECTED]> wrote:
> [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
>
-------------------------------------------------------------------------
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
