I don't know if this has been asked before, but what are your
thoughts on adding a "Configuration Settings" screen to the control
panel that would allow admins to dynamically create
$PROGRAM_CONFIG_FILE_DIR and adjust some of its settings via the
Web interface?
At the moment, I have no plans to do this
The reasoning is that the
dada_config file is a very important file
- if it gets corrupted - if there's one error, the program stops
working
If the wrong people get access to it, the program can get
hacked
Easily
I would rather not have a web-based way to change the
global config settings
The file is also non-trivial to edit - it's basically a perl script
itself, which means any sort of Perl syntax can be used - and I fail
to see how having a web-based textbox with just a dump of this
information is anything better than manually editing it via FTP/SSH
So, what would be better would be to get out of the Config
pm file
things that shouldn't be there anymore - like all the HTML screens
and Email messages that are hanging out for no reason
This has been
how the Config
pm file usually evolves - new settings are placed
there to be changed Globally, and, if it makes sense, removed from
there and made a list setting
I don't think we'll see this being
done in 2
10, but we'll slate it for 2
11, since that's the kind of
changes that should be made then;
What you probably want to do is have a separate program generate
the
dada_config file for you, which is just as well, but there's no
way that a program like that will be able to as flexible as hand-
editing the file
I guess I'd be all for some sort of program, but
it's a little off my radar at the moment - it can be created as a
separate project, basically
And second, & more importantly: the fact that you're planning bug- fix releases on a significantly ramped-up schedule from version 2
10 forward means that a lot more people are going to benefit from
using $PROGRAM_CONFIG_FILE_DIR (so installing each new 2 [current] x release doesn't delete/override their Config pm
settings) and, consequently, making its creation and
configuration as easy as possible should probably become a higher
priority
The $PROGRAM_CONFIG_FILE_DIR variable has been in Dada Mail since,
like 2
5/2
6 - it's not a new feature by any stretch of the
imagination
I don't quite see how a pending release makes this more
of an issue, if people are using it, they're using it, if they're
currently not, they probably won't be in the future
The reason why you don't have to use an outside configuration file is
because it's way, and I mean, way over the head of the average
installer of Dada Mail
Making a new file, adding bits of Perl code
in it, saving it at a specific location, hooking that up to the
Config
pm file - that's a lot of steps
So the outside config file is
optional - if you want to spend the time to learn what you're doing,
you benefit by saving time in the future - you don't want to use it,
easier initial install
So thinking out loud to myself, it looks like what would be the most
beneficial would be an installer to Dada Mail - something that'll
generate the outside config file, install everything where it has to
go and hook it all up correctly - which is a great idea, but again,
it's a little out of the pale of what I want to do
My, "pale" is
time and what I can fit inside it :) But again, a good outside
project that could tie into Dada Mail;
Justin Simoni
Start a new thread, email: dadadev@dadamailproject.com
This is the developer discussion mailing list for Dada Mail.
If you are just looking for support Dada Mail, consult the message boards at:
https://forum.dadamailproject.com
Documentation for Dada Mail:
Specifically, see the Error FAQ:
https://dadamailproject.com/d/FAQ-errors.pod.html
To post to this list, send a message to:
mailto:dadadev@dadamailproject.com
All subscribers of this list may post to the list itself.
Topics that are welcome:
Dada Mail is on Github:
https://github.com/justingit/dada-mail/
If you would like to fork, branch, send over PRs, open up issues, etc.
This Privacy Policy is for this mailing list, and this mailing list only.
Email addresses collection through this mailing list are used explicitly to work within this email discussion list.
We only collect email addresses through our Closed-Loop Opt-In system.
We don't use your email address for any other purpose.
We won't be sharing your email address with any other entity.
Unsubscription can be done at any time. Please contact us at: justin@dadamailproject.com for any help regarding your subscription, including removal from the mailing list.
All mailing list messages sent from us will include a subscription removal link, which will allow you to remove yourself from this mailing list automatically, and permanently.
All consent to use your email address for any other purpose stated at the time of the mailing list subscription will also be revoked upon mailing list removal.