From: Jason B. N. <jb...@tr...> - 2001-07-23 04:37:29
|
Gang, I started a web-based configure (native PHP). But I have a small problem. Check out the new files in /etc for the scoop. They are in the SM2 cvs. Later. j Jason Bradley Nance jb...@tr... http://www.tresgeek.org/ - When we walk to the edge of all the light we have and take a step into the darkness of the unknown we must believe that one of two things will happen: There will be something solid for us to stand on or we will be taught to fly. -Patrick Overton, "Faith" -- |
From: Peter H. <pet...@hu...> - 2001-07-23 16:25:16
|
> Gang, > I started a web-based configure (native PHP). But I have a small > problem. Check out the new files in /etc for the scoop. They are in the > SM2 cvs. Do you guys think that this should be an sm2-api thing. In other words, should the user be able to plug in different types of config front ends? Like "old style perl config", "new PHP config", "ESP config", etc. Or, should we just have the one, php based config? If we go this way we can do it hybrid, so it can be web or CLI. -Peter |
From: Jason B. N. <jb...@tr...> - 2001-07-23 16:32:48
|
Peter Hutnick wrote: > Or, should we just have the one, php based config? If we go this way we can do > it hybrid, so it can be web or CLI. The code that I put in there is standalone. It doesn't have anything to do with the API. It even has its own auth stuff. Just so you know... =) j -- Jason Bradley Nance jb...@tr... http://www.tresgeek.org/ - When we walk to the edge of all the light we have and take a step into the darkness of the unknown we must believe that one of two things will happen: There will be something solid for us to stand on or we will be taught to fly. -Patrick Overton, "Faith" -- |
From: Paul J. T. <cap...@sq...> - 2001-07-23 18:29:37
|
>> I started a web-based configure (native PHP). But I have a >> small problem. Check out the new files in /etc for the scoop. >> They are in the SM2 cvs. > > Do you guys think that this should be an sm2-api thing. In other > words, should the user be able to plug in different types of > config front ends? Like "old style perl config", "new PHP > config", "ESP config", etc. > > Or, should we just have the one, php based config? If we go this > way we can do it hybrid, so it can be web or CLI. Hmmnn... By its very nature, sm2-api/zookeeper will contain the backend functionality to make writing various configuration frontends just a matter of implementing the particular interface. This is all well and good for the web based interface (WBI?). However, this may not work as well for a CLI. I know that the current configuration script is written in Perl, which is going to have a hard time working with Zookeeper (which for now, at least, is just php). Of course, there is the option of writing a CLI php script for configuration, instead of Perl. However, this depends on people having their environment set up to be able to run php scripts from the command line. This isn't hard to do. However, one of the big goals of Squirrelmail is for it to be easy to set up. That won't be the case if someone has to figure out how to run a php script from the command line first. Maybe we go ahead and write the php CLI version, for those who would be interested, and a web version for the rest. We can organize the code such that it could be easy for someone to lock the config section down, or something. -- Paul Joseph Thompson cap...@sq... |