Hi Stephen, phpMailer and SwiftMail are both LGPL and ZF is Open BSD, so I don't think it's really an issue for most users.
In any case, if licensing was the problem, why not put a clear 'alert' label on the Cake component informing everyone that it only really exists for licensing reasons. The majority of us wouldn't then waste any time. I suppose the book is being fair when it says "There is a lot that it doesn't do for you but it will get you started." Hmm, more like get you frustrated and ready to move on to a fully-featured working library. I will propose a 'diplomatic' amendment to the book. On Jun 12, 9:35 am, Stephen Orr <[EMAIL PROTECTED]> wrote: > I think the thinking is that, by not including external solutions > wherever possible, it keeps the licensing clean, making it easier for > bigger companies to adopt for their own projects. The trouble with > including most external libraries is that they're GPLed, which tends > to mean that the entire source code to the application needs to be > released under GPL as well. The MIT license Cake is released under is > just a little more friendly... > > SwiftMailer is good though! > > By the way, Zend have similar rules with the Zend Framework libraries. > > On Jun 12, 1:31 am, villas <[EMAIL PROTECTED]> wrote: > > > Same here. I struggled with the Cake component but then put my trusty > > phpMailer in vendors and bingo, my emails were soon flying again. > > > I now cannot see the point in Cake developers spending their time on > > this Email component when there are such robust, fully-featured > > solutions available to be 'wrapped'. It goes completely against the > > DRY principle. How on earth are they expecting to write, update and > > support anything better than phpMailer or SwiftMailer? > > > Sorry about the rant, but I hope the Team will review the real point > > of this component. And, when they do, I hope the conclusion isn't, > > "Other email libraries are just as good and better, but they weren't > > invented here". Once the Team goes down that route, we'll next be > > having a homegrown Cake alternative to JQuery. > > > On Jun 10, 8:49 pm, ianmcn <[EMAIL PROTECTED]> wrote: > > > > While waiting for replys to this, I tried using the Pear mail script > > > as a Vendor and got it working within about 30 seconds! Thanks for the > > > replies, they have confirmed that it's probably best for now to stick > > > with a more mature mail system. > > > > On Jun 10, 3:09 pm, BrendonKoz <[EMAIL PROTECTED]> wrote: > > > > > You could also use the Zend framework's email classes as a vendor if > > > > need be. Before the Cake email component was created, that was what > > > > my original plan was for sending email. There are plenty of tutorials > > > > on using the Zend Framework's email class. (Don't think of the Zend > > > > Framework as a competitor if you've already chosen Cake. Cake is a > > > > full stack framework, Zend is a skeletal framework, you can and should > > > > use it where and when you can.) > > > > > On Jun 10, 9:46 am, "Jonathan Snook" <[EMAIL PROTECTED]> wrote: > > > > > > > I am trying to use the new email component in cake 1.2, but am > > > > > > having > > > > > > problems using it with an authenticated SMTP server. I am getting > > > > > > the > > > > > > following error: > > > > > > 503 5.5.2 Send hello first > > > > > > Not to knock the core developers but the email component still needs > > > > > some work, especially in support for SMTP extensions like AUTH. My > > > > > recommendation would be to use SwiftMailer (there are CakePHP > > > > > components which a google search is likely to uncover but I'm too lazy > > > > > to do myself). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
