> So, on Unix, would it be $HOME/.freenetrc, or $HOME/.freenet/.freenetrc ?
$HOME/.freenetrc. Because only state information should go in .freenet. > I thought the directly was quite a good idea, because we have a few files > we need to store. I thought we could put the data store there, too, The data store currently does go in .freenet. And it deals fine with running multiple copies, storing the datastores of multiple nodes all in .freenet. > The other consideration is that if you make the Java do one thing on > Windows, and something else on Unix, then it's "un-java-like". I believe > HotJava Browser does (or at least used to) use the Unix convention, which, > translated directly to Windows, became C:\.hotjava\... But, then, of > course, there are more Windows users to consider than anyone else. Why > don't I just use the Unix convention for now and we can refine it later? You should use the configuration file naming conventions for the operating system which the distribution is for. We're not making a single distribution, we're making one per OS with OS-specific scripts and configuration files. > Is it all right if I have 'remote' configuration that only accepts > connections on localhost? > The other option would be to have the client modify .freenetrc directly. > Perhaps then we could have the equivalent of a -HUP signal that works by > connecting to the right port. The advantage is security: unauthorized > users could only make the node reload its configuration, which would have > no exploitable effect. I think I will go with this instead, if that's all > right with you guys. This is a much better idea. But why do you need a -HUP signal that can be sent remotely? Why not just have the configurator kill the node process and restart it? Unless you're talking about running the configurator remotely, which I see no need for. > How would configuring from stdin work? If the frontend launches the node, it has control over its stdin and stdout so it can use those to send commands without having to worry about authentication. > There are plenty of clients that have a configuration file (like ssh, > wget, cvs, ...). This file could be edited directly for the command line, > and the GUI could share the same file, and allow GUI editing. I can't see > any problem with this...? I was just saying I didn't see why a CLI client could write out a modified config file. But now I see what you mean and this is fine. > Hmmm... And what do you think of the idea of the node having an HTTP proxy > built in (disabled by default)? Again, I'm think of all this from the > point of view of ease of use by an ordinary Windows user (to use the most > respectful term I can think of.) It's enough to get them to run one > daemon (hence the idea of the client spawning the daemon). I see HTTP > proxying as the most important feature from a user's point of view. This would be just an GUI. I think a nice looking GUI with buttons and stuff would be preferable but this might be nice. I don't know about built-in, but maybe. I think that's something we should think about and put a bit off into the future. Look at fproxy, BTW, for something similar. It's not a proxy, but then proxies are harder to set up than servlets/cgi/mini-webservers. > Another possibility is for the user not to run a node, but to run the > client only, and have the client pointed at the network somehow (by means > of this same magic mechanism for a node to join the network). The client > could then be configured to run an HTTP proxy itself, just for the period > during which the client is running. This would be an ease-of-use thing > for OWU's. No, every user should run a node. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
