hard coding of paths

[David Everly]

I would like to suggest that paths no longer are hard coded, but instead
configured at run time. This will allow more flexibility within Emilda.

For a rationale, please see:

http://www.onlamp.com/pub/a/onlamp/2005/03/31/packaging.html

Page Two (Configuration Techniques) of the above is especially relevant.

The configuration can be accomplished via apache mod_env's SetEnv
directive.

I've attached a patch based on emilda-1.2.2 that appears to accomplish
this. I'll also attach a sample emilda section of httpd.conf that can
be used to set these values. These are currently set for how the Debian
package is installed, but can be easily changed to work with where you
have installed emilda on your system.

The new variables are:

# What is the base url path to access emilda within the browser
# (used in src/perl/MARC.pl and src/perl/book_manager.pl). Example:

SetEnv emilda_alias_url_path /emilda

# What is the base url path to access emilda's cgi scripts
# within the browser (used in src/user_add.php, src/book_add.php,
# src/book_edit.php, src/pdf.php, and src/book_manager.php).
# Example:

SetEnv emilda_cgi_url_path /cgi-bin/emilda

# What is the directory that contains all the configuration files
# (used in src/lib/config.inc, src/lib/db.inc, src/perl/PDF.pl,
# src/perl/MARC.pl, src/perl/barcode.pl, src/perl/book_manager.pl,
# and src/setup.php). Example:

SetEnv emilda_config_dir /etc/emilda

# What is the directory that contains the emilda "private" perl
# module(s). This is used by src/perl/barcode.pl,
# src/perl/book_manager.pl, src/perl/MARC.pl, and src/perl/PDF.pl:

SetEnv emilda_perl_dir /usr/share/emilda/perl

# What is the directory that is writable by the web server and
# contains information related to the variable state of emilda (used
# by src/setup.php and src/index.php). Example:

SetEnv emilda_var_state_dir /var/lib/emilda

There may be better ways of doing this, but I wanted to at least show
one possible way.

Thanks,
Dave.
--
Encrypted Mail Preferred:
Key ID: 8527B9AF
Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF
Information: http://www.gnupg.org/

ASCII ribbon campaign:
() against HTML email
/\ against Microsoft attachments
Information: http://www.expita.com/nomime.html

[Mattias Nordstrom]

Post by David Everly
I would like to suggest that paths no longer are hard coded, but instead
configured at run time. This will allow more flexibility within Emilda.
http://www.onlamp.com/pub/a/onlamp/2005/03/31/packaging.html
Page Two (Configuration Techniques) of the above is especially relevant.
The configuration can be accomplished via apache mod_env's SetEnv
directive.
I've attached a patch based on emilda-1.2.2 that appears to accomplish
this. I'll also attach a sample emilda section of httpd.conf that can
be used to set these values. These are currently set for how the Debian
package is installed, but can be easily changed to work with where you
have installed emilda on your system.

This is definately something that will be implemented, but I have a
feeling it is more part of the restructuring effort that will go into
Emilda 1.3. As part of that effort, a more package friendly structure
should be a high priority.

I don't think this will be part of the 1.2 branch however. The dust is
starting to settle around it and this would be a bit too much. Or
perhaps it could be implemented to some extent. Either way, 1.3's
purpose is to address issues like these, which may be a good reason to
wait and not implement it in 1.2 as the way 1.3 will deal with these
things is not known yet.

Thanks for the patch and ideas!

[David Everly]

Post by Mattias Nordstrom

Post by David Everly
I would like to suggest that paths no longer are hard coded, but
instead configured at run time. This will allow more flexibility
within Emilda.
http://www.onlamp.com/pub/a/onlamp/2005/03/31/packaging.html
Page Two (Configuration Techniques) of the above is especially relevant.
The configuration can be accomplished via apache mod_env's SetEnv
directive.
I've attached a patch based on emilda-1.2.2 that appears to
accomplish this. I'll also attach a sample emilda section of
httpd.conf that can be used to set these values. These are
currently set for how the Debian package is installed, but can be
easily changed to work with where you have installed emilda on your
system.

This is definately something that will be implemented, but I have a
feeling it is more part of the restructuring effort that will go into
Emilda 1.3. As part of that effort, a more package friendly structure
should be a high priority.
I don't think this will be part of the 1.2 branch however. The dust is
starting to settle around it and this would be a bit too much. Or
perhaps it could be implemented to some extent.

Since I have to change these hard coded values anyway in the Debian
package, it has been implemented there.

Post by Mattias Nordstrom
Either way, 1.3's purpose is to address issues like these, which may
be a good reason to wait and not implement it in 1.2 as the way 1.3
will deal with these things is not known yet.

I will be interested to hear of other ideas for doing this in 1.3 as
they become known! So far I can only come up with Apache configuration
as a bootstrap mechanism, which can then point to a configuration
directory which could contain further .ini files as needed.

I'm still working on and have concern with a few other areas to make
this concept "complete". The main area that I'm concerned about is that
there are things left to the _Emilda_ administrator that are most likely
the domain of the _System_ administrator, such as:

config_key="log_file"
config_key="barcode_path"
config_key="barcode_url"
config_key="zebra_path"
config_key="zebra_config"

I would like to urge the removal of these from the database (where the
Emilda admin controls them) and instead make them easily set up by the
Apache or System Administrator as part of the installation process.

The qualities these items share in common are:

* they are related to the installation of the software (or to the
installation of software required for Emilda to function)

* it does not add value to change these after software installation
unless the location or source code of the installed software itself
changes

So, I would be interested in your thoughts and the thoughts of anyone
who would join this discussion. And if there is agreement, some ideas
of where such items would move to (apache config? .ini file? other?).

I know I don't say this enough: Emilda is great! Thanks for making it!

Dave.
--
Encrypted Mail Preferred:
Key ID: 8527B9AF
Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF
Information: http://www.gnupg.org/

ASCII ribbon campaign:
() against HTML email
/\ against Microsoft attachments
Information: http://www.expita.com/nomime.html

[Mattias Nordstrom]

Post by David Everly
Since I have to change these hard coded values anyway in the Debian
package, it has been implemented there.

Yea, we didn't really make it package friendly, sorry 'bout that ;)

Post by David Everly

Post by Mattias Nordstrom
Either way, 1.3's purpose is to address issues like these, which may
be a good reason to wait and not implement it in 1.2 as the way 1.3
will deal with these things is not known yet.

I will be interested to hear of other ideas for doing this in 1.3 as
they become known! So far I can only come up with Apache configuration
as a bootstrap mechanism, which can then point to a configuration
directory which could contain further .ini files as needed.
I'm still working on and have concern with a few other areas to make
this concept "complete". The main area that I'm concerned about is that
there are things left to the _Emilda_ administrator that are most likely
config_key="log_file"
config_key="barcode_path"
config_key="barcode_url"
config_key="zebra_path"
config_key="zebra_config"
I would like to urge the removal of these from the database (where the
Emilda admin controls them) and instead make them easily set up by the
Apache or System Administrator as part of the installation process.
* they are related to the installation of the software (or to the
installation of software required for Emilda to function)
* it does not add value to change these after software installation
unless the location or source code of the installed software itself
changes
So, I would be interested in your thoughts and the thoughts of anyone
who would join this discussion. And if there is agreement, some ideas
of where such items would move to (apache config? .ini file? other?).

Emilda currently limits these options to the root (in Emilda) user,
which is intended to be the sys admin. You make a good point however,
the system paths should perhaps be outside Emilda, as they can't be used
without system access anyway.

The Emilda setup process will be redone for 1.3, as setup.php isn't very
package friendly and could be easier for the user too. We'll have to
reopen this discussion when the time comes to implement this. Hopefully,
Emilda will be so versatile that creating packages from it (.deb, .rpm,
etc) will be a trivial task.

Post by David Everly
I know I don't say this enough: Emilda is great! Thanks for making it!

Thanks for packaging it!

Post by David Everly
Dave.