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]

Reply via email to