Seperation of Mail-classes (was Mail_Box RFC (?))

i partly agree with that too. I definetly would reduce some overhead. But you always have to watch out for common functionality that might be used in each of those classes, that should not be copy-pasted. The naming for those different packages might be an issue to think about. For the mailing, i would suggest: since there is already a package 'Mail' i think we might create packages such as Mail_Box_POP3 Mail_Box_IMAP Mail_Box_... I think the prefix Net_ should be used here for the protocol implementation. The common classes, such as Mail_[Box_]Message and Mail_[Box_]Attachment for building and reading those parts could be seperate packages which might be used by the above listed classes. opinions? Lukas Smith wrote:

From: Yavor Shahpasov [mailto:yavo@siava.org] Sent: Tuesday, July 15, 2003 2:32 PM I actually posted a message about this a while ago, that some common packages should follow the same api and if not possible to implement a function should return a not supported error. for example instead of making one class which has different

subclasses,

you cold have classes which follow the same api (implement an interface if

you

will), in that way you would not not need to care whether it is a

Net_POP3

class NET_IMAP class or a NET_MBOX class or even a NET_Maildir (I wish

:O)

class. this should be applied to many places in pear

I agree. Actually I just started a little discussion that goes into a similar direction on pear-qa@ Regards, Lukas

-- Wolfram ... opensource @ vision:produktion ... http://opensource.visionp.de ... authentication system .... http://sf.net/projects/auth