Re: PEAR on Win32

Most of what I've seen of CPAN's name space is sensible, so I don't see why not? It gives me a funny feeling though. :-) - Stig Andrei Zmievski wrote: > > Why don't we just copy CPAN's namespace? :) > > On Sun, 27 Aug 2000, Sterling Hughes wrote: > > > > > > Mail/SMTP > > > > > > > > > > I'd actually like to break this one out into a seperate hierarchy: > > > > > > > > > > Mailer/SMTP > > > > > Mailer/Sendmail > > > > > Mailer/PHP > > > > > > > > > > > > > I don't know about this, I think that SMTP clearly fits into the Mail > > > > catagory. So does Mail/Sendmail > > > > > > Okay... maybe then: > > > > > > Mail/Mailer > > > Mail/Mailer/SMTP > > > Mail/Mailer/Sendmail > > > etc... > > > > > > It's a bit more typing, but I want a common interface between the classes > > > that send mail - if Mail/ also contains Mail/POP, then it isn't the place > > > for that API, but it should exist, which is why I'm suggesting Mailer/ or > > > Mail/Mailer. > > > > > > > I think this would be better, otherwise it'll get real confusing with Mail > > and Mailer being on the same level. Still imagine writing a program: > > > > <?php > > > > include_once 'Mail/Mailer/Sendmail.php'; > > > > $mh = Mail_Mailer_Sendmail::connect ("servername"); > > ?> > > > > Any more levels and it'll get real ugly. > > > > Another option if you want a common API why not name it Sender.php, then > > place it in Mail: > > > > <?php > > include_once 'Mail/Sender.php'; > > > > $mh = new Mail_Sender(); > > ?> > > > > > > Also I don't see the reason for any class besides Mail/SMTP for sending > > e-mail, most Mail servers (placing foot in mouth) are SMTP anyway right? > > Why interface with Sendmail? What other protocols are commonly used for > > sending e-mail (Perl, as far as I know, only supports Mail::Sendmail, which > > uses SMTP). > > > > > > Why not just keep it all in Mail? > > > > > > No reason - just typing. But it does fit there. > > > > > > > Perhaps we should have a message subclass: > > > > > > > > Message/HTML > > > > Message/MIME > > > > Message/* > > > > > > Urg. An HTML email _is_ a MIME email. Just a specialized kind of one. That > > > should be strangled. Err, did I say that? > > > > > > > I tend to agree with that sentiment. =) > > > > > And back at you: why should Message/ be outside of Mail/? > > > > > > Too many inter-related not-quite-standards... > > > > > > > Aggghhhh! > > > > I agree Message belongs in Mail but then again can you imagine: > > > > <?php > > include_once 'Mail/Message/MIME.php"; > > > > $mh = new Mail_Message_MIME(); > > ?> > > > > Not the most elegant solution, just one too many levels. > > > > I'd say Message is a clearly defined subject and deserves a top level > > directory. > > > > > > as well as a MIME sub-folder for non-message related topics. > > > > > > > > This could get a bit complicated, but I think MIME/application/msword > > and > > > > MIME/Message shouldn't be in the same sub-class (you had to put msword > > in > > > > there:-). > > > > > > Yeah... Hmm. Maybe MIME/application/msword is a bit specific to have in > > PEAR > > > - maybe we should provide a MIME/viewer interface that applications can > > > implement to handle various types... > > > > > > > Agreed, MIME/viewer could call MIME/application/msword, but the advertised > > class would be MIME/Viewer (Sort of like what is done with the Mail::Tools > > package in Perl). > > > > -Sterling > > > > > > -- > > PHP Extension and Add-on Repository (PEAR) mailing list. > > Documentation can be found at > > http://pear.php.net/doc/pear.html > > To unsubscribe, e-mail: php-pear-unsubscribe@lists.php.net from the > > mail address you subscribed with. > > > > -Andrei > > "When I get a little money, I buy books; > and if any is left I buy food and clothes." -- Erasmus > > -- > PHP Extension and Add-on Repository (PEAR) mailing list. > Documentation can be found at http://pear.php.net/doc/pear.html > To unsubscribe, e-mail: php-pear-unsubscribe@lists.php.net from the > mail address you subscribed with.