All,
Bizarrely, I did not actually receive Scott's message - only the two
things Marc quoted.
> > * Rename .freenetrc to $HOME/.freenet/node.properties
> >
> > * Give the client a configuration file also, called
> > $HOME/.freenet/client.properties
> >
> > * We could put everything else in this directory also. I'm sure you
guys
> > all have opinions about this stuff, so let's have 'em.
> You really can't get away with the above changes, since $HOME is a unix
> specific feature and Freenet is supposed to be cross platform.
I was speaking figuratively. I really meant
System.getProperty("user.home") (or whatever it is)...
>> * Rename .freenetrc to $HOME/.freenet/node.properties
>
>The proper naming covention for a UNIX configuration file is .xrc where x
>is the name of the program. the proper naming convention for a windows
>configuration file is x.ini. I don't know about macs. I don't think
>anything should go in .freenet other than state information.
>
>> > * Give the client a configuration file also, called
>> $HOME/.freenet/client.properties
>
>A client configuration file is a good idea. But the same things apply as
>above.
So, on Unix, would it be $HOME/.freenetrc, or $HOME/.freenet/.freenetrc ?
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.
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?
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).
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.
> Why not configure from stdin? And I agree with Scott about the
> dubiousness of configuring running nodes. We rejected remote
> administration many times.
How would configuring from stdin work?
>> * Client configuration is written/read by running client.
>
>For the GUI, sure. I don't know how that would work for the CLI, but it
>seems bad.
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...?
>> * Initially a node can run without a properties file, but it will sit
>> there and do nothing except listen on its configuration interface
>> (localhost only).
>
>It should just use the hardcoded default properties like it does now.
OK, I won't shag about with it. I'm sure we can dream up some automatic
way of a new node joining the network that doesn't require any
configuration. (Ease of use.)
>> * Node software complies with JDK 1.1 spec, client software complies
> with
>> JDK 1.2 spec.
>
>The CLI client should compile with 1.1 and the GUI should compile with
>1.2
>OR 1.1 with the Swing library installed.
OK - done. I've got 1.1 here somewhere.
>Reuse as much code between the CLI and GUI client as possible. Move any
>duplicated code into the client library.
I certainly will.
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.
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.
Steve
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
