I second perrin's suggestion above regarding using flat files if the data is small enough.

Another option to consider is to let the caller hand you an open file handle (or an IO::File object). That gives the caller full control over where to put the data, so your modules becomes portable to platforms you don't know about yet. Furthermore, it would allow passing in a tie'd filehandle to play games you haven't thought of.

Why not make a base class and subclass it with a way to do it with dbm's. Then, subclass to use MySQL (or whatever). People can subclass to use with whatever data store they wish to use (a DB, flat file, directory structure, etc...) that way your design will make it more portable.

Also, look on the CPAN, and search Google for ways other are maintaining state, so you don't re-invent any wheels.

Cheers,
KM

Otherwise, something like File::HomeDir might assist in homesteading your files.

Simply assuming "current directory" is asking for trouble if you ask me, whether it be from inconsistencies, security issues, or permission problems.

Matt

I agree with Matt in that perm problems will cause errs on your scripts. You could get around them by installing with uid 0, but that would be bad. What about letting them specify a state config file? Maybe /etc/myApp.state?

I'd make the location and/or filename more explicit to the module user, and the filename at least in one constant somewhere so it can be changed trivially if needed.

In fact, isolating the save/restore logic is a good idea in general, so the whole thing could be replaced without affecting the rest of the module.

Here is an example that should give you an idea of how this works. I prefer using the tied method because IMHO it is easier to work with an HoH than a bunch of method calls.

use Config::IniFiles;
#  my $cfg = new Config::IniFiles( -file => "configfile.ini" );
# or
my %ini
tie %ini, 'Config::IniFiles', ( -file => "configfile.ini" );

# do stuff with %ini

# create a new section and add values
$ini{new_section} = {};
$ini{new_section}{new_param1} = $val;
$ini{new_section}{new_param2} = $val2;

# add a multiline value
$ini{new_section}{new_param2} = [$value1, $value2, ...];

# save with the TIED hash 
# overwrite the current ini file
tied( %ini )->RewriteConfig();
# or you can write to a different file
#tied( %ini )->WriteConfig ($NewFilename);

# save with object ref
# overwrite the current ini file
#$cfg->RewriteConfig();
# or you can write to a different file
#$cfg->WriteConfig ($NewFilename);
[download]

This is portable and human readable! :)

--
hiseldl

You should probably use the operating system's normal per-user configuration solution because (1) you want to build on what the user already knows, and (2) you don't want one user of the module screwing up other users.

On a Windows box, the right answer is almost always the registry. Just check $^O and then eval Windows-specific versions of your history module. The registry is really easy to use with the Win32::TieRegistry module:

 use Win32::TieRegistry ( Delimiter => '/' );

 my $key = $Registry->{'HKEY_CURRENT_USER/Software/MyModule/History'};
 my $dir = ($key ? $key->GetValue('Cwd') : 'C:/';
[download]

On a Unix box, the right answer is almost always a dot file in $HOME. Make sure the home directory is really the user's home if you execute things from your history file. (You probably want to do the same checks if you use Data::Dumper because that can eval code.)