Dear,
NTDOC
Kent wasn't repeating us. His goal was that he can install the kixtart binaries into
another directory ("c:\scripts")
Also it can be necessary that you must install kixtart on your clients. F.e. we are running
all kind of scripts in the background without the requirement of a network connection.
Also during logging on and with the speed of current networks such installation isn't necessary.
During logging on we will always updating our kixtart binaries on the clients without using our
control file to skip this element. Also such update isn't a big problem by modem connection.
Lonkero
Indeed we have said before, but sometimes the information must be complete.
Indeed we have already deployment package for 3.xx. When we are modifying our installation
scripts in a significant way we update them all. Such moments were
- when the control file was changing from format and location
- when we were installing onlyt the required kixtart binaries on NTx environments
- when we were restyling the way of creation and removing file associations
Why?
- the way it works is the same for all versions. so we will not get questions "why doesn't work
that capability on our version" and "can you implement them also in this older kixtart version".
- debugging is much easier when we are using the same scripts in all packages. output should
look always the same.
- helping people is also much easier and not only for us.
Of course it is possible that we are using the new features of kixtart in this process,
but it hasn't any priority for us. Packages work at the moment and new one can be created
automatically. Simply one mouse click in our situation.
Also the amount of required time for running is also very acceptable.
kdyer
Kent, we were just joking a little bit about the reduction factors. Just during the
analyse of your version we see some nice things and also we see why we can't implement
them all at this moment. The same script should run also on oldest kixtart package
release. Also we know that your goal was to reduce our code a little bit and we want
to give your other ideas about further reduction. For other (new) members we show
that they can reduce their scripts also without modifying them before.
Once we were using two significant different versions of "kixstrip", which was very
hard to maintain.
About backwards compatibility:
when people where using an earlier version of our packages during deployment we must
cleanup the mess from those earlier versions.
when people where using only latest versions of our packages it isn't necessary to
do that. In our script above we doesn't use "c:\kix???.ok" at all. We have to deal
only with the "%windir%\kix???.ok" control file.
For people using the old format of deployment we create also the second control file
"c:\kix???.ok". The old format is meaning here
code:
if not exist c:\kix420.ok %0\..\kix420update /q
The new format is
code:
if not exist %windir%\kix420.ok %0\..\kix420update /q
Kent, we like your humour. Only we must prevent that other people without internal knowledge
of those scripts think "why so much bytes necessary".
We suggest that people are keeping always the original source. Original source contains f.e.
comment. An reduced version can be hard to maintain. We don't think, that you of anybody else
love it to modify our reduced version with variable names like $x1, $x2, ...., $x35.
About parenthises
some language makes it possible that you are using short versions of available keywords.
of course typing the short ones doesn't cost much time, but reading those code many
years later make it very hard to understand what it means and to maintain.
Using parenthises makes in our opinion code much easier to read. Something similar
with "specifying default results" and "layout of structures" and "not using GOTO's".
Using a good indentations makes it very easy to find back the position where
to insert f.e. the missing ENDIF in your script. No indentations is exactly the
opposite of it.
Some elements for good programming in our opinion is:
- other people can easily read what it is doing without the requirement of have
depth knowledge of that language.
- other people can modify code in an easy way for their own purposals.
- other people can easy maintain code or implement new functionality.
and
that they don't write a complete new version of your script and
that they don't throw away your version because modifying is too hard for them.
About variables without reference
we only mention them. We know you are working still on a final version. Sometimes we
publish different versions of our scripts and tools in a very short time, when we
need to incorporate member's feedback.
About going back ... with the 3.6 version
everything is incorporate in same script. So we aren't going back. Not only in the
recent kixtart releases people want to have the capability of installation only the
required kixtart binaries. Also an implementation by using another SYSTEM DRIVE is
a very good extension.
More about it you have already read.
Kent, we appreciate always your input and feedback. When our feedback shows a negative
manner it wasn't our goal. Apology for that. Possible we were choosing the wrong words,
but we never mean that.
We agree with you that we also implement stuff for a number of people. For our situations
many things weren't implemented at all. Kent, do you know how many questions the MM-club
guys put on this board? We think not so much. Most of their input is for helping others.
Kent, keep on going.
greetings.
[ 02. May 2003, 04:10: Message edited by: MCA ]
