hi Daniel, > when I look at /ext/ (PHP source) just to pick a random example: > what's 'vpopmail' doing there (no personal offense to the author, > really randomly picked)? I mean, vpopmail has it's own deamon and an > interface written in PHP (ok, that one is ugly, it depends on global > variables and has to be rewritten), but why create a /compiled/ module > for this? doesn't make sense to me. no gain in performance. and even > the module is WORSE than the PHP interface, because it requires you to > run PHP as CGI binary, fiddling around with sudo etc.. (whereas the > PHP just opens a socket to the vpopmail-daemon, sends some commands > etc..)
i would not like to put any offense but you are technicaly wrong - the fastest way to access vpopmail functionality is to call native api instead execute something external. this can be observed on high loaded servers of course. one cannot skip the sudo stuff with vpopmail anyway - you must be root to manage domains, and at least vpopmail to manage users. when one really need to manage vpopmail at high web load she can compile a separate apache for the management site and run it under vpopmail instead using slow CGIs. prehapse you mess vpopmail with vmailmgr - the first one have management daemon, second does not (at least an official one). the third reason is the unified interface - vpopmail command line tools differ between versions and one have to tweak her script for each different version. about the first part of your email - i would vote with two hands for PEAR repository of php modules written in C, vpopmail extension's place is definitely there > anyone interested in /ext/daniel/ printing out some greetings to my > friends? how about daniel_greet_his_friends(); and > daniel_send_email_to_his_friends(), etc? :)) b. -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]