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.ser
vices- 
> 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

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php