[dev] setup/config

Marko Djukic marko at oblo.com
Mon Apr 7 01:30:15 PDT 2003


i've been playing around with the setup script, but i've ran into a number of
problems. i've been aiming to do the following:
- securely get around the problem of webserver write permissions for config
files
- have something user friendly, interactive and less error-prone which could be
run and rerun to update/change config
- obviously be OS independent
- use a common code base whether it is run from the CLI or the browser or
whatever else

the problems with CLI:
 - creating php-pure dialog boxes is a nightmare, simple text and enum prompts
are ok, but with things like big (>10 choices) enums and multienums it started
getting unmanageable.
 - code which could be shared i need to move it into the cli specific class and
create alternatives for code like Horde::fatal(). which bloats the cli class
too much. which then raises the question should we be making such a beefed up
CLI interface duplicating a lot of the main horde code if it is going to be
used relatively little? and it does not seem to make sense having code like
Horde::fatal() interface independent.
 - this is the same with horde_forms code, started emulating its code within the
CLI dialog box code, bloating the CLI code yet it doesn't make sense having
horde_forms interface independent.

what are the alternatives?
- how can we stick with the browser as the user-friendly install mechanism? is
there a way to get around the file-system write permissions? if anyone has used
cups, how do they do that browser based user/pass authentication to modify the
file system? is it that they have a mini-webserver as part of their code? could
we use a dedicated mini-webserver as part of the "admin" package for horde? a
good example could be the nanoweb server written in php (main code base only
60kb from what i can tell).
- use something like phpgtk?
- use dialog/whiptail type of dialog managers? anything available for windows?

i personally like the idea of a dedicated mini-webserver at first glance. it
maintains the clean web-oriented code, seems like a secure option (run on a
secure port, behind a firewall, ask for user auth, etc etc), and a relatively
small increase in code (60kb, whilst i'm already at 20kb with the unfinished
CLI code and it's looking crap).

marko


More information about the dev mailing list