8 Apr
2002
8 Apr
'02
noon
Hi,
the development team would like to announce that the only official domain name for this
project is
http://phpmyadmin.net (which currently points to http://phpmyadmin.sourceforge.net).
Thanks.
--
Marc Delisle
8 Apr
8 Apr
2:22 p.m.
On Mon, Apr 08, 2002 at 11:57:00AM -0400, Marc Delisle wrote:
the development team would like to announce that the
only official domain name for this project is
http://phpmyadmin.net (which currently points to http://phpmyadmin.sourceforge.net).
yes, phpmyadmin.org and phpmyadmin.com are owned by people
willing to make money by selling the domain names. They have
*nothing* to do with the phpmyadmin devel team.
Greetings,
Olivier
--
_________________________________________________________________
Olivier Mueller - om(a)8304.ch - PGPkeyID: 0E84D2EA - Switzerland
qmail projects: http://omail.omnis.ch - http://webmail.omnis.ch
2:56 p.m.
On Mon, 8 Apr 2002, Olivier M. wrote:
On Mon, Apr 08, 2002 at 11:57:00AM -0400, Marc Delisle
wrote:
But I see from the whois records that you own it Oliver!
;-)
Either way, it's good to have it.
Thanks.
Just a note. My week of final exams is April 15th -> 19th, and then I am
taking a week off relaxing, after which, I will be resuming a lot of work
on phpMyAdmin.
Your database stored configuration should be ready in a month or so. It
presently exists as a table by the name of 'config' in my database, and
just works barely. I need to improve a lot of it still before it's ready
for any other development work, and I want to make it more extensible.
For work on it, there is one thing I need to ask about. Would it be
feasible to get the existing code written to use a pair of functions,
pma_getvariable($name) and pma_setvariable($name,$data) whenever we are
dealing with a configuration variable? That would be used to 'hide' the
configuration system from the other developers, and reduce possible
problems. I am using the PHP serialize/unserialize to store data in the
database presently.
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
the development team would like to announce that
the only official
domain name for this project is http://phpmyadmin.net (which currently
points to http://phpmyadmin.sourceforge.net).
yes, phpmyadmin.org and phpmyadmin.com are owned by people willing to
make money by selling the domain names. They have *nothing* to do with
the phpmyadmin devel team.
3:16 p.m.
Robin Johnson a écrit :
Just a note. My week of final exams is April 15th -> 19th, and then I am
taking a week off relaxing, after which, I will be resuming a lot of work
on phpMyAdmin.
Your database stored configuration should be ready in a month or so. It
presently exists as a table by the name of 'config' in my database, and
just works barely. I need to improve a lot of it still before it's ready
for any other development work, and I want to make it more extensible.
For work on it, there is one thing I need to ask about. Would it be
feasible to get the existing code written to use a pair of functions,
pma_getvariable($name) and pma_setvariable($name,$data) whenever we are
dealing with a configuration variable? That would be used to 'hide' the
configuration system from the other developers, and reduce possible
problems. I am using the PHP serialize/unserialize to store data in the
database presently.
Robin,
I am not against using functions, but:
- what about the existing arrays in config.inc.php3?
- implementing pma_getvariable() all over the code will be a lot of work, so I suggest
before
starting this, to think also about a possible User Preferences module (db-stored also).
--
Marc Delisle
3:55 p.m.
On Mon, 8 Apr 2002, Marc Delisle wrote:
I am not against using functions, but:
- what about the existing arrays in config.inc.php3?
That is the reason I was using
serialize and unserialize to store the
data. Those functions preserve arrays perfectly.
- implementing pma_getvariable() all over the code
will be a lot of
work, so I suggest before starting this, to think also about a possible
User Preferences module (db-stored also).
Could we decide on which of the options
in the current configuration
should be available to each user in their personal preferences?
Since it will just be the redefinition of some of the options from the
main configuration, I propose doing it like this:
Read in the master 'config_master' table.
Read in a client override table 'config_user' which is contains all the
fields of 'config_master' plus one additional field for the username.
The options for 'config_user' are set over the existing 'config_master'
options.
Voila! You have user preferences. But we would need to put some security
on that 'config_user' table, as there are probably some things that we do
not want the user being able to change.
Also, looking at the security functions of this, as well as the speed
considerations, using a database configuration system will REQUIRE a
system that supports sessions, otherwise you risk poor performance
(re-reading the configuration data on each page). By using sessions, it
could be loaded once on login, and then re-loaded if the user changes
preferences.
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
9 Apr
9 Apr
1:01 p.m.
Robin Johnson a écrit :
For example, let's talk about $cfgShowBlob and assume that this can be
a master and a user pref.
I guess you have put a "ShowBlob" field in the config_master table.
It would be more flexible not to have the actual cfg variable names
as fields, but as data, so the config_master table would have 2 fields:
the cfg variable name, and the cfg variable value (possibly serialized).
Maybe a third field to indicate if this can be overriden by the user
(indicating a possible search in config_user).
This is because we have to think about future PMA upgrades and avoid
users having to add fields to config_master.
What do you think of that?
On Mon, 8 Apr 2002, Marc Delisle wrote:
Ok.
I am not against using functions, but:
- what about the existing arrays in config.inc.php3?
That is the reason I was
using serialize and unserialize to store the
data. Those functions preserve arrays perfectly. - implementing pma_getvariable() all over the
code will be a lot of
work, so I suggest before starting this, to think also about a possible
User Preferences module (db-stored also).
Could we decide on which of the options
in the current configuration
should be available to each user in their personal preferences?
Since it will just be the redefinition of some of the options from the
main configuration, I propose doing it like this:
Read in the master 'config_master' table.
Read in a client override table 'config_user' which is contains all the
fields of 'config_master' plus one additional field for the username.
The options for 'config_user' are set over the existing 'config_master'
options.
Voila! You have user preferences. But we would need to put some security
on that 'config_user' table, as there are probably some things that we do
not want the user being able to change.
Also, looking at the security functions of this, as well as the speed
considerations, using a database configuration system will REQUIRE a
system that supports sessions, otherwise you risk poor performance
(re-reading the configuration data on each page). By using sessions, it
could be loaded once on login, and then re-loaded if the user changes
preferences.
It is ok for me to require sessions for this, you are right about performance,
and also because this will be an optional configuration mecanism.
Keep on the good work!
--
Marc Delisle
11:08 p.m.
On Tue, 9 Apr 2002, Marc Delisle wrote:
For example, let's talk about $cfgShowBlob and
assume that this can be
a master and a user pref.
I guess you have put a "ShowBlob" field in the config_master table.
It would be more flexible not to have the actual cfg variable names
as fields, but as data, so the config_master table would have 2 fields:
the cfg variable name, and the cfg variable value (possibly serialized).
Yes, that
is how I was considering doing it.
But there is one additional layer I had considered.
In the initial load of variables, we would do them in this order:
1. load variables from configuration file (base defaults and
username/password for database access initially).
2. if configuration type is database, read in config_master
3. if configuration global allow user override, read in config_user on
fields that have allow_override set in the config_master table.
4. in the config_user table, if allow_override is set, then the user can
change that preference on their own. Otherwise the admin must set it for
the user.
This is because we have to think about future PMA
upgrades and avoid
users having to add fields to config_master.
What do you think of that?
Yes. it would be good.
Maybe a third field to indicate if this can be
overriden by the user
(indicating a possible search in config_user).
Here are my two table structures
that I have been playing around with:
CREATE TABLE config_master (
option VARCHAR(255) NOT NULL DEFAULT '',
value TEXT,
allow_override BOOL NOT NULL DEFAULT '0',
PRIMARY KEY (option),
KEY allow_override (allow_override)
) TYPE=MyISAM COMMENT='Master Configuration Options';
CREATE TABLE config_user (
user VARCHAR(255) NOT NULL DEFAULT '',
option VARCHAR(255) NOT NULL DEFAULT '',
value TEXT,
allow_override BOOL NOT NULL DEFAULT '0',
PRIMARY KEY (option),
KEY allow_override (allow_override)
) TYPE=MyISAM COMMENT='User Configuration Options';
Looking at this, there are some questions I have, for people.
should the 'value' column be BLOB type or TEXT type?
How large will the data be? Could we shring it to TINYTEXT/BLOB or
VARCHAR(255) ?
It is ok for me to require sessions for this, you are
right about performance,
and also because this will be an optional configuration mecanism.
Ok.
For security reasons, I also propose doing away with the 'only_db' option,
as it is only a very poor substituate for proper user rights in MySQL.
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
8196
days inactive
8197
days old
6 comments
3 participants
participants (3)
-
Marc Delisle -
Olivier M. -
Robin Johnson