Hello Andy,
First, let me say thanks for sharing all of this. We don't often get detailed feedback on these things. Your valuable insights will be used to make later releases better.
With that said I will add a few comments here and there to explain why things are the way they are and help others achieve their goals (which might be different).
Saturday, October 4, 2008, 2:12:47 AM, you wrote:
Hi,
Didnt realize I had been uninstalled for a few months.
I saw that V3 was released, so I gave it a shot. I unzipped the installation files to a new /SNF folder. All files were expanded into the same folder (your zip file had not subfolders!).
The vast majority of SNF installations on Windows systems keep all SNF components in the same folder. So, for the majority of folks SNF is simply decompressed into "it's own folder", configured, and launched. This makes things simple and there is no question where to find things.
Along the way we have been asked for the ability to put logs in a different location, get rulebsae files from a different location, configuration files, and so forth. We've added those features so that the folks who have reason to move things around can do so.
We decided not to create a presumed directory structure for SNF because the folks who've asked us to provide these features all had their own unique way to divide things and move them. Any structure we created would have been wrong for most folks, so we keep the single folder option as our default since it is what everyone was used to and what most of our customers have been using.
SNF is used on a lot of platforms -- each with their own conventions. Not only that but within each platform administrators and user communities develop their own preferences.
The paths/ section described next allows folks to manipulate some file locations according to user preferences.
Following the instructions I customized the XML files.
I noticed THESE parameters:
node identity='D:/IMail/declude/SNF/identity.xml'
paths
log path='D:/IMail/declude/SNF/Log/'/
rulebase path='D:/IMail/declude/SNF/Rulebase/'/
workspace path='D:/IMail/declude/SNF/Workspace/'/
/paths
Im a believer in keeping different data in their distinct subfolders, so I set up the /Log, /Rulebase and /Workspace subfolders by hand and updated the XML file.
The I took a wild guess that SOME files would have to be moved into those subfolders but there are NO instructions WHAT files go WHERE for things to actually work!
The current documentation is located here:
http://www.armresearch.com/support/articles/software/snfServer/config/node/paths/index.jsp
The general design is such that log files will be written into the log path, the rulebase file will be read from the rulebase path, and the remaining files should reside in the workspace path.
I will add a task to clarify this in our documentation and provide more detail.
I found it annoying that further down in the same XML File was yet another path that was NOT included in the paths node in the top of the XML file:
update-script on-off='on' call='D:/IMail/declude/SNF/getRulebase.cmd' guard-time='180'/
The configuration file is organized by function. The top of the configuration file and in particular the paths/ section is concerned with describing the architecture of the SNFServer installation.
The update-script/ feature is a component of the networking section because it is triggered by SNF network operations, so we put it's configuration information in that section.
This feature is still evolving -- in it's original design it was presumed that the update script would reside in the single SNF directory, or perhaps in the workspace directory -- so only the name of the script would be required in this location. We actually have had quite a few successful installations this way.
However, along the way we've determined that the update script might be located anywhere on the system and that we could not always assume the current workspace for SNFServer indicated the location (or even a relative location) for the udpate script.
To prevent errors we've taken to coding the full path to the script in this section of the configuration.
Another part of the thinking on this is that the update-script feature is completely optional. In fact many of the larger systems that we service use entirely separate update mechanisms and turn this feature off. It seemed to make more sense to put the script path closer to the network features that trigger it.
Next I had to customize the getRuleBase.cmd because it too does NOT support the use of the rulebase/workspace paths. Here was yet ANOTHER place where I had to manually configure the same path information again, as well as the license key. Needless to say, Im not a friend of having redundant path information in several locations as this is an unnecessary source of error.
This is an unfortunate, but necessary
