[isf-wifidog] Re: PATH troubles in Wifidog - and some more thoughts

Benoit Gregoire bock at step.polymtl.ca
Lun 4 Sep 09:12:16 EDT 2006


On Sunday 03 September 2006 23:10, Max Horváth wrote:
> - gpg control packet
> Hey guys,
>
> just a question: how do handle the path defines at the command line?
>
> I.e. right now I don't have a clue how to run the cron scripts as
> with php-cli there is no DOCUMENT_ROOT and stuff like that.

I had made the necessary modifications so that the mail script would only 
require WIFIDOG_ABS_FILE_PATH, .  From the command line, most other path's 
simply make no sense.  Defining them would just cause the failure to occur 
further in the code.

For testing, I presume you would want to use the GUI methods.  There is 
actually code to manually define the low level paths.  You'd need to add the 
same facility for BASE_NON_SSL_PATH and could then define it in your test 
scripts.

> Now it's also getting harder as I started writing unit test and the
> cli doesn't know the path's of course ;) ...
>
> I know this topic has been a mess for a long time - why don't we just
> switch to hard coded path defines in the config.php before the 1.0
> release? All the trouble would be gone :)

We can't define them in config.php, or it wouldn't work out of the box on most 
webservers like it does now.  

In the begining, the file paths were defined through an explicit relative 
definition of the basepath at the top of every PHP script.  I still think 
this was clearer and simpler, and I wouldn't mind going back.  It would make 
your basic commandline problems disapear overnight.  We are kind of doing the 
equivalent by doing a relative include on common.php, and reverse engineering 
it from there.  While needlessly complicated, it should work just the same 
from the command line.

The other part of path detection (the one dealing with URLs) is quite frankly 
fine now.

> Cheers, Max!
>
> PS: Anyone working on the PDO implementation? Or any thoughts about
> it, yet? Design docs / thoughts?

Now that we don't ever intend to support MySql, In practice converting 
everything to PDO only gives us prepared statements, and a more standart 
database syntax.  

If we don't want to loose our SQL profiling functions (that just went back in) 
and make it possible to do a progressive transition.  We can get the same 
benefits by doing the following:

1-Pourting our current AbstractDb to PDO
2-Rename all the current methods in the class deprecated_methodName, and 
search and replace in the whole tree.
3-Make the class inherit from PDO, and make the standard PDO functions log to 
our profiler.
4-Progressively move to the new syntax.

That would work, but I'd say it's a "If someone feels like it" priority.


> PPS: Being maybe revolutionary in this mail, what about seperating
> the classes folder into a package installable via PEAR? :) :) :) It
> could solve / ease dependency problems when installing Wifidog auth
> server.

How?  None of our dependencies except for a few RADIUS ones are part of PEAR 
anyway!


Plus d'informations sur la liste de diffusion WiFiDog