The question is whether to leave this as an example or to make it (or
something like it) the default.
OK, here is what I am thinking. Forgive me while I think out loud...
I am sympathetic to Shad's argument that people should have a simple
way to use spreadsheets. I am also sympathetic to the notion that
different people may want the spreadsheet layed out in different ways.
I am trying to think of a clean design which would make it easy for
Perl novices to configure this stuff.
It really comes down to specifying three things:
1) Which spreadsheet(s) to use
2) Within each spreadsheet, how to find the record you want
3) How to map the fields of that record into unattend.txt settings
(Some people might want to use something other than a spreadsheet,
like a SQL database. We should allow that easily too.)
Perhaps we should provide some helper functions to make this sort of
thing easier to write and to read.
The first step is to add some indirection. Some people want to locate
their spreadsheet entry by MAC address. Others (like yours truly)
want to prompt the user for an asset tag number and locate the entry
that way. Others might want to look it up by Dell service tag.
So, I think we should store the hardware and software records in a
pair of new keys:
$u->{'_meta'}->{'hardware_record'} =
sub {
# Here we have code to find the hardware record and return
# a reference to an associative array. (I bet you didn't
# know you could store one of these in an
# Unattend::IniFile. Well, you can.)
# We can provide sample code to locate this record by MAC
# address, asset tag, and Dell service tag.
};
$u->{'_meta'}->{'software_record'} =
sub {
# Similarly, but for software. Russ doesn't want a
# separate software spreadsheet, so he would just put this
# here:
# return $u->{'_meta'}->{'hardware_record'};
# ...thus making the software record the same as the
# hardware record, letting him put his license keys in the
# hardware speadsheet.
};
We could provide default implementations for these subroutines which
we think make sense (Shad's implementation). Or we could just leave
them as examples. I am leaning towards the former, although I am
still open to arguments. But mostly, I want to get this interface
right.
The code for Shad's [UserData]/FullName setting would then look like
this:
$u->push_value ('UserData', 'FullName',
from_record ('_meta', 'hardware_record', 'Owner'));
Here, from_record() is a helper routine we will provide which returns
a subroutine to do the desired lookup, returning undef if it is
cannot. (I am glossing over the definition of "cannot"... Should an
empty field return undef? Let's worry about that later.)
This provides a simple (well, simpler) way to declare that the
[UserData]/FullName setting should come from the 'Owner' field of the
hardware record.
Similar 1-2 liners would let you declare all the other settings which
come from the spreadsheets.
Maybe from_record() should assume '_meta' as the default to make the
code shorter.
Anyway, those are my musings. Comments?
- Pat
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
unattended-info mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unattended-info
