Re: [NEW EXTENSTION]: templates

Boian Bonev wrote: > > 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 There's one alternative for each hand you vote with: PEAR or PECL. Extensions that go into PEAR have to follow PEAR's naming conventions, stuff in PECL does not. You find these two in CVS: pear and pear/PECL. - Stig