Re: Re: Net_Vpopmaild

On Nov 4, 2007, at 8:01 AM, Christian Weiske wrote:

My first idea was to have a vpopmail driver only, but then I didn't know about the advanced features. I had the same problem with my Services_Blogging package: There is base functionality across all weblog apis, but nearly every implementation has additional features. The way I went was to create a "basic" and an "extended" driver interface which the drivers could implement. (See http://pear.php.net/manual/en/package.webservices.services-blogging.php section "Drivers") In our case, there won't be enough enough drivers and similarities in advanced functionality IMO to have a base for an extended driver. So the vpopmail driver could just have additional methods that are not in the driver interface, but nevertheless available and documented. As soon as further drivers with similar functionality come out, we could decide about more "extended" interfaces, or even an API to discover supported functionality (eg. by querying "isSupported(Mail_Admin::SOME_FUNCTIONALITY)").

Is this how DB or MDB2 works?

For the question about whether to have a vpopmaild standalone package: Someone using the Mail_Admin package and needing to use advanced functionality that is not covered by the driver, but the vpopmaild package itself, you need to create a "native" object additional to the Mail_Admin driver instance - which is double work. Of course the driver could always wrap all the functionality of vpopmaild, but then the question is whether a separate package is needed at all.

Other advanced features of vpopmaild include tiered permissions built into the vpopmail API, including domain level (add/remove users), system level (add/remove/modify domains), and user level (just password changing, vacation messages, forward mail, etc)

administration.       There's also some low level access like adding/removing files and directories (based on the above permission levels) that gives the vpopmaild client great control over manipulating .qmail files directly for added flexibility (like custom filtering apps, custom vacation/autorespond programs, tmda, etc).  It allows you the same level of control that Qmail does via .qmail files.

I've spent a lot of time implementing all of the vpopmaild commands, and think that some folks would find a direct OO implementation of vpopmaild in PEAR really useful. I also see the value of your above suggestions. Mail_Admin requires MDB2 to talk to the postfix database. Why not just have it optionally require Net_Vpopmaild to talk to vpopmaild, and have a lightweight driver to implement the core Mail_Admin functionality? If someone needs full access to vpopmaild functionality, then can use Net_Vpopmaild instead. That would keep Mail_Admin's API simple. And please correct me if I'm wrong, but I suspect that vpopmail's advanced features are more involved than other virtual mail packages, making it the exception rather than the norm with regards to driver implementations for Mail_Admin. Regards, Bill Shupp