Pete McNeil wrote:
My take on this is again from the lowest common denominator (you must put on your newbie cap to have the correct perspective). The choice doesn't depend on what might save a step, but instead, what is more straightforward, and a cleaner approach. Putting the update script in a separate directory is both. Personally, I have ended up with a bunch of files in my Sniffer directory that I don't use, and I can see a user accidentally deleting a file that might be necessary for updates to occur. Can it work otherwise? Of course, I'm just suggesting my own personal view of what I consider to be 'optimal'.On Wednesday, December 29, 2004, 2:31:18 AM, Landry wrote:
<snip/>
MB> 2) I personally find it to be a bit messy to have everything MB> running from within my Sniffer directory. After all of the MB> other CMD files, old rulebases, service related files, logs, MB> etc., it's not obvious what is needed or not. I would MB> suggest coding this up with a default directory structure of MB> using a subdirectory called "updates". This would require a MB> separation of variables for the updates directory and the MB> destination directory I believe.
LW> What do others think about this? My goal was to keep things LW> as simple as possible for the end user of the script. However, LW> if people think that a separate "updates" directory makes more LW> sense, then I can make this change.
IMO (with 20/20 hindsight) having updates happen in the sniffer working directory seems to lead to much of the complexity of the script... Realizing that this thought is in conflict with my previous post (that the update mechanism should be able to function safely within the sniffer working directory) it might be _simpler_ on the whole to have it separated.
To test this - am I correct in guessing that an update done in a
separate directory could skip most of the renaming work of the current
script(s). That is, the download step would bring in a new .snf file
right on top of the existing one. Then the file would be tested and
either placed into service or discarded depending upon what snf2check
says about it. The rest of the operation (archival et al) would be
optional and all of the renaming associated with collision avoidance
could be eliminated. (I think I think too much... I should think about
that).
MB> 3) I think it would be a good idea to consider a differentConsidering that the best way to run an update script under the current environment in IMail is to utilize a program alias, this update script therefore becomes mail server specific. On the other hand, there is no reason to create a separate directory structure for every Windows server because it causes complexity and confusion to the end user. At some point in Sniffer's growth, this will become an even bigger issue, and now is one opportunity to start moving towards some form of standardization. Promoting the use of "C:\Sniffer" as the top level directory for all Windows installations would have a net positive effect in the long run, especially when people share scripts such as these, or for installation support. Promoting that directory however should only be perceived as the default choice, not by any means the only choice, but that will be up to the end user to change.
MB> default directory structure. With Sniffer evolving to
MB> support other platforms, IMail effectively abandoning us, and
MB> Declude moving to SmarterMail and possibly others, I could
MB> very well see Sniffer establishing a non-dependant directory
MB> structure. I would suggest that the default recommendation MB> become "C:\Sniffer", which might also necessitate a change in some
MB> of Pete's other documentation. Keep in mind that it is
MB> confusion and convolution that contributes to the lack of
MB> efficient rulebase downloads and not the lack of resources or
MB> help. IMO, things would benefit from standardization of this
MB> sort, and it should all be done with purpose.
LW> Yes, but this script was focused only on IMail users. Does LW> it make more sense to create different scripts for different LW> platforms, or a single script with a platform specification LW> variable?
Personally I've never thought that any "standard" update script should
be IMail specific --- it just ended up that way (a little). There
should be IMO only two "standard" update scripts. One for *nix users
and one for Win32 users.
From the newbie's standpoint, I completely agree about the complexity (hence my recommendation). From me personally, this isn't an issue.MB> 5) I'm thinking that including the notification process MB> within this script might be too much. The primary goal is to MB> get people to use the automated system and compressed files, MB> and this adds complexity to the setup. My thought here would MB> be to create a "chaining" option that could be used to kick
<snip/>
LW> Again, this script is focused only on IMail users. If we LW> follow your suggestion in section 4 above, then why move the LW> e-mail report out of the basic script?
IMO there is a lot of complexity here.
The notification scheme could expand into a menagerie of logging, email, and action mechanisms.
To simplify this then why not simply prepare a stub that optionally calls a notification script with a variable. The variable indicates either success or failure.
The notification mechanism can then evolve on it's own as a separate
problem. ?
I figured that eliminating tertiary tasks would simplify the instructions, the script, and therefore the entire implementation. The goal is to make it easy for as many people as possible to implement. The hook to call another script I don't believe should be documented anywhere but the script itself in order to simplify, and if it was my script and Sniffer was my business, I would probably personally choose to let the modders (power users) take care of it for themselves.
LW> Let see what Pete and others on the list think. If we canIMO, the goal here isn't necessarily to reach a consensus, it's to make things easier, more accessible to the novice, and more widely implemented. If this was based on my own personal needs, as I stated before things would be different. I wouldn't expect a consensus to necessarily reflect the best choices under these conditions. Maybe it's just a matter of establishing 'agreement', and primarily so according to Pete's direction.
LW> come up with a basic consensus, then we can run with it. LW> Whatever we decide, I would welcome your help.
Once an agreement is made, I would be happy to test the scripts, and also work on any other piece that you wish to ask of me, so just ask when the time comes. Naturally, very few ever have to ask for my opinions :)
Matt
-- ===================================================== MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =====================================================
This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
