All, > 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.
OK. I'll just leave the names the same as they are now, but I think a good idea is to make it so the Java code uses the current directory, but the wrapper scripts always change into a particular directory ($HOME or C:\WINDOWS). This way in development we can use our own scripts and run multiple nodes, and for end users, they get a single location for all configuration. > > 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. All right, let's make the wrapper scripts determine all the platform-specific stuff. Ultimately for Windows we can have a wrapper .EXE (as many apps do) so the whole thing is easy to install and use. > > 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. Only because, if you are writing pure Java, this is very difficult to achieve. > > 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. The problem I can see with this is that the node needs to to keep running after the client stops, and then the link would be severed. In a perfect world, the client would have a traffic-lights style stop/start button that automatically starts and stops the node, and when you exit from the client, the node keeps running. I'd love to do this, but I can't see a straight-forward way in Java. The above can be the ultimate goal. I'll just leave it out until I can think of some clever way of doing it. Perhaps the wrapper script can somehow do all the yucky platform-specific stuff. > > 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. Yes, my plan was to integrate fproxy, not change it (unless it needs changing). Perhaps the HTTP proxy could either be standalone, or run as part of the client, at the user's discretion. Perhaps it doesn't belong in the node. Perhaps it does. Incidentally, I do proxies and HTTP stuff, too, in case that skill is needed. > > 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. If you force users to run nodes, then you will get zillions of people running a node on a dialup modem for 15 minutes at a time. This would kill the network. Surely it's better to let them freeload than bugger up the network. (My facts may be wrong here.) Almost everyone I know uses the Internet, but only two people other than me have a cable or DSL connection. The price will have to come down a LONG way before there's much of a dent in the dialup user base. New Zealand is relatively advanced, I think. (Compared with the U.K., anyway, which maybe isn't saying much.) Steve _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
