All, > > 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, > > because I am a great believer in software being simple and not having > > unnecessary options. In development we'll need to run multiple copies > > under the same user (so I could allow for that somehow), but I can't see > > any reason why an end user would do that. > > Well, in nfreenetd (a C implementation of a Freenet node), I am going > to store the configuration file at /etc/nfreenetd.conf and store the > datastore under the /var/spool/freenet directory (with the datastore > index being at /var/spool/freenet/index). The reason for this > arrangement is that I think that a Freenet node should be treated more > as a system service (like mail transfer agent, print spooler, or a > NNTP server) than a user level program. This philosophy is also one > of the reasons why it isn't a bad idea to have a Freenet node > implemented in C.
I suppose the Java implementation's primary role is as a reference implementation, but of course it should be fully functional and interoperable with other implementations. (I'm sure others will see it differently.) Perhaps it's going outside the Java version's role to be treated as an integrated Unix service - I don't know. That's why I'm think more 'user-centric'. What do others think? As Brandon said, you have to be root to run it. That's not just a hassle - it's also a security risk. > > On remote configuration: > > > > > This is just a bad idea. Please do not allow remote configuration. Its > > > never necessary to change the configuration of a running node anyway. > > > > Is it all right if I have 'remote' configuration that only accepts > > connections on localhost? It's attractive, because it's an easy way for > > the client to find the running node, and I like convenience of use. > > Trouble is, (on Unix) it doesn't authenticate the client's user id. I > > thought I could get around this by optionally allowing a password, but > > that leads on to remote configuration, which we're not going to do (now > > that I know). > > This is unnecessary and a waste of time. Why couldn't you just SSH > into a box and do the configuration through that (assuming it is a > Unix/Linux box)? I'm not doing this now. (That reminds me of all the Windows guys at a place I worked being surprised that one of our Unix admins could set up a new production system in another city without going there. They were all ready to put him on a plane!) > > > Why not configure from stdin? And I agree with Scott about the > > > dubiousness of configuring running nodes. We rejected remote > > > administration many times. > > > 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. > > I don't deny that HTTP proxying is a good idea, but I don't think that > it should be integrated into nodes themselves. I think that the most > appropriate place to put HTTP proxying is in a HTTP<->Freenet > gateway (or you could do a similar thing with a SMTP<->Freenet > gateway). In accordance with the general consensus, I'll treat the proxying as a separate service from the client's perspective. > > 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. > > Ideally, we want as many people as possible running nodes. Anyways, > with how a node would work, you wouldn't really even need to have a > node be shut down while the network connection is down. When the > network connection is down, the local Freenet node can be used to > cache (like an HTTP cache used by a Web browser) so that one does not > have to save files that they saw on Freenet to access them while > offline. A Freenet node should be started up when the computer starts > up and shut down when the computer shuts down/reboots. Yes. The same should be true for Windows. But should the Java version do this? Steve _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
