Re: Net_Vpopmaild

Hello Bill, (lets move the discussion to pear-dev) >> I saw that you requested a pear account to propose a vpopmail >> administration package. >> I created one myself for postfix - it supports a driver based >> interface, so if you would write a vpopmail driver, we'd have the >> same >> API across different mail backends. This in turn would allow us to >> write a GUI that supports this different backends. > Interesting, I had not seen this. Are you proposing a driver > instead of Net_Vpopmaild, or in addition to? Vpopmail has features > outside of standard aliases, accounts, and domains, such as limits > (limit accounts, limit access of pop/imap/smtp on a per account or > per domain level), and in the future support of ezmlm list > management. So my initial reaction is that Net_Vpopmaild should > exist, but a driver for Mail_Admin to access it through your existing > API is also a good idea, and I'd be happy to work on that. 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)"). 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. In PEAR, we have several packages which use a driver based infrastructure (DB, MDB, MDB2, Services_Blogging, Image_Canvas). Some of them have a main package and release their drivers as independent "subpackages". In all cases, this works quite well and I see no reason why it would not be the same in our case. So I opt for having all the net_vpopmaild code integrated into Mail_Admin and not creating an additional driver that wraps another class's functionality. -- Regards/Mit freundlichen Grüßen Christian Weiske

Attachment: [application/pgp-signature] signature.asc