Proposal for Mail::Mail_Admin

Christian Weiske (http://pear.php.net/
user/cweiske) proposes Mail::Mail_Admin.

You can find more detailed information here:
 http://pear.php.net/pepr/pepr-proposal-show.php?id=504


-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

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

Till Klampaeckel (http://pear.php.net/use
r/till) has commented on the proposal for
Mail::Mail_Admin.

Comment:

I like the idea to provide a unified API to numerous
mailservers/installations. (But I just have no idea how to
test this since
my postfix setup is pretty different. ;))

Is your driver based on some opensource project (e.g.
postfixadmin or
pmwh(2))?

Some things I noticed:
1)
Sometimes you just throw a regular "Exception".

2)
I think your Exceptions should be "stacked", e.g.
all come from
Mail_Admin_Exception() to allow catching *all* exceptions
which related to
your package in a single catch.

3)
Sometimes you echo errors inside the class.

4)
Also, would driver and base class be seperated?

5)
MDB2 should be an optional dep since not all drivers will
use a DB.

6)
The one class per file rule, or did that get dropped?


P.S.
Linking directly to your code would be a huge plus, since
your WebSVN is
pretty "crowed". ;)

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=504


-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

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

Christian Weiske (http://pear.php.net/
user/cweiske) has commented on the proposal for
Mail::Mail_Admin.

Comment:

Till, thanks for the comments.
I changed the status to "proposal" to gather
feedback from other devs -
but I failed to mention in which areas 

To your notes:
0) The code is completely new, not based on some other
project
1) Will be fixed, I just needed to get it work for a project
of mine
2) Same as 1
3) Debug leftovers 
4) Do you mean putting Mail/Admin/Driver/Base.php into
Mail/Admin/?
5) I will be optional dep once we have more drivers
6) Has to do with the open issues I have.


My problems so far:
- Anyone who has ever setup any mail server with user
account data stored
in a RDBMS/LDAP: Is the distinction into Alias, Mailbox and
Domain common?
(Mailboxes and aliases belong to domains, and aliases
redirect to either a
mail box or a different email address not on this server)
- The package uses a driver-based approach. A driver
potentially comprises
multiple classes. Should the class names have the same
"base name" like
Mail_Admin_Driver_Postfix resulting in class names like
Mail_Admin_Driver_Postfix_Alias - or should I extend the
names of classes I
extend to get names like
 Mail_Admin_Alias_Postfix
 Mail_Admin_Mailbox_Postfix
?

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=504


-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

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

On 11 Sep 2007 08:03:54 -0000, Christian Weiske
<cweiskephp.net> wrote:
> (...)
> 4) Do you mean putting Mail/Admin/Driver/Base.php into
Mail/Admin/?

Maybe that too - I was more after, if the Postfix
"driver" would be a
seperate package later on, but I guess your other replies
made that
obvious now. 

> (...)
> My problems so far:
>
> - Anyone who has ever setup any mail server with user
account data stored
> in a RDBMS/LDAP: Is the distinction into Alias, Mailbox
and Domain common?
> (Mailboxes and aliases belong to domains, and aliases
redirect to either a
> mail box or a different email address not on this
server)

I think the distinction is common, but it does not really
make any
sense.  At least
in my opinion, it makes more sense from a user
perspective to just say "mailboxes" and then your
mailbox can be
forwarded (alias, forward) or picked up (-> to
mbox/maildir).

But of course you need to implement the magic to do
everything in the
background.

CGPro works the same way, atmail as well. Exim, Qmail etc..
too. CGPro
and atmail are the only commercial packages I have
experience with.

> - The package uses a driver-based approach. A driver
potentially comprises
> multiple classes. Should the class names have the same
"base name" like
> Mail_Admin_Driver_Postfix resulting in class names
like
> Mail_Admin_Driver_Postfix_Alias - or should I extend
the names of classes I
> extend to get names like
>
>  Mail_Admin_Alias_Postfix
>
>  Mail_Admin_Mailbox_Postfix

I like to have things on Mail_Admin_Driver_Postfix_* - but
that's my
personal preference. Is your question regarding
"looks" or more in
regard to implementation?

Cheers,
Till

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

Till,


> Maybe that too - I was more after, if the Postfix
"driver" would be a
> seperate package later on, but I guess your other
replies made that
> obvious now. 
Separating drivers into packages makes sense as soon as
there are 10+
drivers IMO.

> I think the distinction is common, but it does not
really make any
> sense.  At least
in my opinion, it makes more sense from a user
> perspective to just say "mailboxes" and then
your mailbox can be
> forwarded (alias, forward) or picked up (-> to
mbox/maildir).
Yes, this is from user perspective. But handling
"hidden" mail boxes
that are only aggregators for multiple addresses, or
addresses that
redirect to several other ones is hard to deal with a simple
user
scheme.

In the application I needed the package for I did exactly
this - allow
the user to choose between a normal mailbox or a redirection
to a
different address. But an API allow deeper modifications.

> CGPro works the same way, atmail as well. Exim, Qmail
etc.. too. CGPro
> and atmail are the only commercial packages I have
experience with.
Good.

> I like to have things on Mail_Admin_Driver_Postfix_* -
but that's my
> personal preference. Is your question regarding
"looks" or more in
> regard to implementation?
From an implementation perspective, class names are
exchangable. But
I'd like to hear how other packages do it (or which way is
recommended).


-- 
Regards/Mit freundlichen Grüßen
Christian Weiske