On Wednesday, December 29, 2004, 2:31:18 AM, Landry wrote: <snip/>
LW> 2) I personally find it to be a bit messy to have everything LW> running from within my Sniffer directory.� After all of the LW> other CMD files, old rulebases, service related files, logs, LW> etc., it's not obvious what is needed or not.� I would LW> suggest coding this up with a default directory structure of LW> using a subdirectory called "updates".� This would require a LW> separation of variables for the updates directory and the LW> 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). LW> 3) I think it would be a good idea to consider a different LW> default directory structure.� With Sniffer evolving to LW> support other platforms, IMail effectively abandoning us, and LW> Declude moving to SmarterMail and possibly others, I could LW> very well see Sniffer establishing a non-dependant directory LW> structure.� I would suggest that the default recommendation LW> become "C:\Sniffer", which might also necessitate a change in some LW> of Pete's other documentation.� Keep in mind that it is LW> confusion and convolution that contributes to the lack of LW> efficient rulebase downloads and not the lack of resources or LW> help.� IMO, things would benefit from standardization of this LW> 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. <snip/> LW> 5) I'm thinking that including the notification process LW> within this script might be too much.� The primary goal is to LW> get people to use the automated system and compressed files, LW> and this adds complexity to the setup.� My thought here would LW> 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. ? <snip/> LW> Let see what Pete and others on the list think.� If we can LW> come up with a basic consensus, then we can run with it.� LW> Whatever we decide, I would welcome your help. I really appreciate all of this effort. THANKS TO EVERYONE! _M 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
