|
Thanks
for all of the suggestions, Matt. See my comments
below:
Bill,
I
think that this is overwhelmingly much better (the whole thing), but I have a
few suggestions to add.
1) The commenting in the CMD file seemed a bit excessive and that made
it a little hard to follow. It might be nice to arrange all of the
tweakable variables in a single section instead of separating each one out,
and then block coding the main program with a standard amount of
commenting. I think that would make the script more readable for both
programmers as well as beginners.
I agree, it might make sense to move most of the instructional comments
out of the script to a separate file that someone could review if they
needed additional help.
2) I personally find it to be a bit messy to have everything running
from within my Sniffer directory. After all of the other CMD files,
old rulebases, service related files, logs, etc., it's not obvious what is
needed or not. I would suggest coding this up with a default directory
structure of using a subdirectory called "updates". This would require
a separation of variables for the updates directory and the destination
directory I believe.
What do others think about this? My goal was to keep things as
simple as possible for the end user of the script. However, if people
think that a separate "updates" directory makes more sense, then I can make this
change.
3) I think it would be a good idea to consider a different default
directory structure. With Sniffer evolving to support other platforms,
IMail effectively abandoning us, and Declude moving to SmarterMail and
possibly others, I could very well see Sniffer establishing a non-dependant
directory structure. I would suggest that the default recommendation
become "C:\Sniffer", which might also necessitate a change in some of Pete's
other documentation. Keep in mind that it is confusion and convolution
that contributes to the lack of efficient rulebase downloads and not the
lack of resources or help. IMO, things would benefit from
standardization of this sort, and it should all be done with
purpose.
Yes, but this script was focused only on IMail users. Does it make
more sense to create different scripts for different platforms, or a single
script with a platform specification variable?
4) Since this setup is targeted specifically at IMail, I would
recommend that different packages be provided for different platforms, and
these should probably be in separate zip's so that one doesn't get all sorts
of extra stuff. This could be "Rulebase_Updater_IMail.zip", but there
should also be a Linux, MDaemon and SmarterMail updater added to the
list.
I agree, but then why section 3 above?
5) I'm thinking that including the notification process within this
script might be too much. The primary goal is to get people to use the
automated system and compressed files, and this adds complexity to the
setup. My thought here would be to create a "chaining" option that
could be used to kick off any script, not necessarily IMail1.exe. You
could then include this separate notification script in the package and have
it configured from within that file, leaving only the optional chaining
command within the primary script and stripping out the rest of the
stuff. I do know that from interface design there is a basic tenet
where you don't want to overwhelm the viewer/visitor, otherwise they retain
even less than they would with a smaller group of things. Programming
is often at odds with this tenet, which is fine for programmers because the
functionality necessitates complication, but the issue being addressed here
is really ease of use for the lowest common denominator, and the primary
goal is just the downloads. You should consider that this whole thing
will be used by people with very little administration experience, no
programming experience, and in some cases, English will be a second language
to them (or only translated by a tool of some
sort).
Again, this script is focused only on IMail users. If we follow
your suggestion in section 4 above, then why move the e-mail report out of the
basic script?
Most of this stuff is
somewhat minor taken in isolation from each other, but I believe that it
could be a bit tighter in one way or another for a better result. I'll
volunteer my own services if you would like for me to provide examples of
any one of these things, but I'll wait for your direction before doing
so. I think the most important thing would be for Pete to provide some
guidance for the preferred directory structure (independent of the app), so
that this could be used for the default settings in this and other
scripts.
Let see what Pete and others on the list think. If we can come up
with a basic consensus, then we can run with it. Whatever we decide, I
would welcome your help.
Bill
-------------------------------------------------------------------------------
This message and any included attachments are from Siemens Medical Solutions
USA, Inc. and are intended only for the addressee(s).
The information contained herein may include trade secrets or privileged or
otherwise confidential information. Unauthorized review, forwarding, printing,
copying, distributing, or using such information is strictly prohibited and may
be unlawful. If you received this message in error, or have reason to believe
you are not authorized to receive it, please promptly delete this message and
notify the sender by e-mail with a copy to [EMAIL PROTECTED]
Thank you
|
|
