On Jan 24, 2008 11:56 PM, Beni Cherniavsky <[EMAIL PROTECTED]> wrote: > On Jan 23, 2008 3:19 PM, Axel Liljencrantz <[EMAIL PROTECTED]> wrote: > > On Jan 23, 2008 2:25 AM, Beni Cherniavsky <[EMAIL PROTECTED]> wrote: > > > > > > * tcp to which host? > > > > The default, in my opinion, should be to use a regular Unix socket. If > > you want a tcp socket, I think it's fair to require you to set it up > > yourself, e.g. _you_ decide this by setting FISHD_SOCKET_DIR to e.g. > > sparks.localdoman:1234 > ... > > With the above approach, none if this is an issue. Or at least, it is > > someone elses problem, which is the same thing. ;-) > ... > > We can only launch a new fishd _if_ we are the specified host. If the > > remote socket is dead for any reason, we're out of luck. > > > You essentially expect the user to maintain a network service. > This is far from trivial, zero-configuration, highly reliable, or safe. > With such weak promises, I doubt people will find it useful. > I think it's only worth doing if it can be made to "just work". > Magically "just working" is one of the cool things about uvars now. > > > > * we should keep the unix socket for local connections, use tcp > > > for remote access only. > > > > I doubt that the performance difference between using 10 tcp sockets > > or using 9 tcp sockets and one unix socket is noticable. > > > Sure. I meant if from the reliability point of view - unix sockets always > work. > But "localhost" also always works, so I take that back. > > > * As Martin pointed out, the security implications are major. We > > _definitely_ need authentication of some sort. By assuming a shared > > home directory, one has effectively created what can be regarded as a > > secure and authenticated sidechannel for this purpose, which is all > > fine and useful, but I would definitely like to avoid writing my own > > authantication mechanism if at all possible - that kind of code is > > error prone. > > > The auth issue is very serious (controlling shell variables easily > leads to executing arbitrary code). > Stupid of me that I haven't considered it before proposing. > > I really believe that using the shared filesystem as the primary and > only channel is better. > * It's simple and easy to implement. > * Making writes atomic is the only hard part. But it's doable. > * It's as reliable and secure as the shared filesystem. > * No configuration needed. Hosts come and go, the files stay there. > > If communicating through files is good enough remotely, it should be > good enough locally. > I want to implement it (hopefully this weekend) and see how well it works. > Do you know anything that I missed which makes it a bad idea? Why is > fishd needed?
Currently, fishd promises that when one command has finished executing, any new command that start executioin on _any_ fish instance will see the new value. I'm not usre how you could make that, or another reasonably good promise on notification speed, without degrading performance significantly. Keep in mind that this holds true also for builtin commands. If you can figure out a reasonable set of tradeoffs using a file as a backend, a basic file should be just as good. Axel > > -- > > 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
