The .ini file is a good idea, as is the version number. I will
definitely adopt them.
I did some hacking this weekend on a Perl module to parse/generate
.ini files. (The current doslib/unattend.pl is too ad-hoc and not
object-oriented.) I am calling it Unattended::IniFile. I intend to
rewrite doslib/unattend.pl to use it, and to use it for the package
management utility.
I began by writing something called a "FoldingHash".
use Unattended::FoldingHash;
my %hash;
tie %hash, Unattended::FoldingHash;
$hash{'FOO'} = 1; # really sets $hash{'foo'}
$hash{'Foo'} = 2; # overwrites $hash{'foo'}
print $hash{'fOo'}; # prints "2"
print keys %foo; # prints "Foo"
In other words, the hash folds key names to lowercase. But it
remembers the key name you used most recently to write to the hash, so
that "keys" can return it. The result is a case-preserving but
case-insensitive hash, which should make Windows-y people more
comfortable.
By using this hash to implement the IniFile object (and other
things...), they will inherit this nice property.
My current thinking on the package management tool goes like this.
Internally, an "atom" is an object which has:
A name
A version number
A set of other atoms it depends on ("requires")
An installation procedure (Perl subroutine)
In the future, I could imagine adding uninstallation procedures,
"Supersedes" (e.g., service packs "supersede" a bunch of hotfixes),
and probably lots of other stuff.
An atom can be defined in several ways:
1) .bat (or .cmd) file with magic comments
The comments look like ":: Name: q813849", ":: Version: 1", or
":: Requires: ie6". The installation procedure is just to run
the file.
This kind of file can only define a single atom. It is also the
easiest to explain.
2) .ini file
This is Kevin's format. Each atom's name would come from its
[section] header, and the other properties would come from the
key=value pairs. (Note: I will probably restrict the atom names
to forbid spaces. Otherwise, writing "Requires" clauses with
multiple atoms gets messy.)
This kind of file can define multiple atoms.
3) Perl code fragment (.pl file)
This is the "big gun" in terms of power; an executable Perl
fragment which defines atom objects directly. I doubt this will
get used much, but I already know cases where I would want it
(e.g., looking up product keys for Office installs). For hackers
only.
Obviously, this kind of file can also define multiple atoms.
4) .txt file ("bundle")
This would be a simple list of filenames, each file being one of
these four types.
This is a quick and simple way to create a collection of atoms.
The package manager will maintain a simple file listing all of the
installed atoms with their version numbers.
Ultimately, installation means running a command. If that command
exits with status 194, that means the atom is requesting a reboot.
(This seems to be Microsoft's convention, so we might as well adopt
it.) This mechanism replaces the .reboot directive.
I also have ideas for dealing with mapping the Z: drive using other
credentials... But this message is already too long.
- Pat
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
unattended-info mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unattended-info
