FWIW, here's some of my opinions regarding clients & install issues:
- While UNIX programs indeed use ".foorc" in many cases, there are many examples of commonly-used UNIX programs that create a ".foo/" directory when the program is complex enough to merit more than a single file. Examples include ELM, SSH, Netscape, and certain XEmacs modules. I believe that Freenet will easily merit additional configuration file types as time goes on, so we should make a .freenet directory and put freenetrc (or whatever) within it. The state information could go into ".freenet/state_info/" or something like that. I would much rather that each application create exactly one dot-file in my home directory. Most of you are probably too young to remember the mess that Mosaic, for example, wraught upon a simple directory display. - It might turn out that many users will run several different clients, customized for different application realms. If a client exclusively uses Freenet for datastore access, I'd rather not clutter up the home directory with a new dot-file for each client. I'd prefer that we create a ".freenet/clients/" directory by default, and encourage client authors to put their configuration/preference files in a self-named ".freenet/clients/foo/" directory. This, also, under the banner of putting all of an app's config info into exactly one directory (unless otherwise specified). - Certainly Steve is quite correct that config/preference info should not be Java-specific. I cringe at the buzzword-of-the-moment aspects of XML, but concede that it is at least worth considering as a format. - Windows prefers that such things go into the Registry, but that may not be appropriate to use as a default in the case of Freenet. IIRC, Windows does have a home directory of sorts, called "My Documents". Many apps do not adhere to those conventions, of course. Personally, I'd avoid the OS directory (typically, "C:/WINDOWS/"). It's already rather cluttered, and some net admins restrict or tightly monitor what goes in there. - If the node is being run in an "underground" fashion, the user should be able to quickly clear out as much evidence as possible that Freenet was ever on that system. We may want to address that issue during the install process. For example, we could have an option to put as much Freenet-related info as possible into a single user-specified directory, and encrypt as much of the contents as possible. Uninstall and standard backup functions would be even better, time permitting. At a minimum, we should keep a good record of what files were created during the install process, and make that record available to the user. - There are probably some good discussions about multi-platform config on a web document somewhere, but I don't have time to look right now. FWIW, though, the TCL language handles multi-platform issues fairly well. It may be worthwhile to look over that model. Here's an excerpt from one page that seemed somewhat relevant... From: http://dev.scriptics.com/man/tcl8.3/TclCmd/tclvars.htm#M12 [...] You can also create your own environment variables for the Macintosh. A file named Tcl Environment Variables may be placed in the preferences folder in the Mac system folder. Each line of this file should be of the form VAR_NAME=var_data. The last alternative is to place environment variables in a 'STR#' resource named Tcl Environment Variables of the application. This is considered a little more ``Mac like'' than a Unix style Environment Variable file. Each entry in the 'STR#' resource has the same format as above. The source code file tclMacEnv.c contains the implementation of the env mechanisms. This file contains many #define's that allow customization of the env mechanisms to fit your applications needs. [...] tcl_rcFileName : This variable is used during initialization to indicate the name of a user-specific startup file. If it is set by application-specific initialization, then the Tcl startup code will check for the existence of this file and source it if it exists. For example, for wish the variable is set to ~/.wishrc for Unix and ~/wishrc.tcl for Windows. tcl_rcRsrcName : This variable is only used on Macintosh systems. The variable is used during initialization to indicate the name of a user-specific TEXT resource located in the application or extension resource forks. If it is set by application-specific initialization, then the Tcl startup code will check for the existence of this resource and source it if it exists. For example, the Macintosh wish application has the variable is set to tclshrc. [...] - I discussed the issue of remote configuration with Scott and Oskar on IRC yesterday. I remain interested in greatly expanding dynamic adjustments to the server's behavior. I would even like to make it a standard (but optional) procedure to have nodes poll & respond to adjustment requests made by authorized outsiders, such as the local network admin. Oskar and Scott think I'm nuts, to put it mildly. :-) Yet even I concede that remote config creates numerous security issues, both direct and indirect. These will be difficult, complex, and time-consuming to address properly. If only for technical reasons, there is no way that the degree of server-supported remote config that I advocate will be a part of the reference implementation of 0.3. Minor adjustments made by programs other than the server, such as the previously-discussed technique of editing the config file & restarting, seemed to be acceptable to Oskar and Scott (please correct me if I misunderstood). I agree that for 0.3 this is the best approach. After we learn from the 0.3 experience, I may raise the subject again. For the moment, however, I think we should spend our time on other issues. It looks like a Freenet variant, rather than the reference implementation, may be the best way to pursue this idea. - Thank you very much, Steve, for your contribution to the project. My time and relevant skills are both limited, but if you are still interested in some quick-and-dirty versions of what you called a "snazzy interface", I have some experience in that arena. Send some rough specs to willdye at willdye.com. Schedule permitting, I can make some semi-functional, explore-the-concept wrappers within a couple of hours. You'll need TCL/Tk to run them. http://dev.scriptics.com/ --Will (not speaking for my employers) willdye at willdye.com _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
