Re: New module Mail::SendEasy
[EMAIL PROTECTED] (Smylers) writes: Personally I found Simon's commentary on some mail-sending modules to be very useful (and I didn't object to his choice of words: when he found something he didn't like he merely said so -- he didn't insult the code's author or make allegations about members of the author's familiar or anything). To be honest, I understand that people get very attached to their work, and in a sense, if you attack their modules, you're attacking them. I'm sure I'd get upset if someone wrote long scathing criticisms of something I'd spent many years working on, even if they did start writing a better alternative; such a criticism can easily be seen to be personal, rather than objective. Even if it's done with benchmarks. -- It is easier to fight for principles than to live up to them. -- Alfred Adler
RE: New module Mail::SendEasy
Title: RE: New module Mail::SendEasy Even if it's done with benchmarks. Just curious, but how well does MIME::Lite fare? Yves
Re: New module Mail::SendEasy
On Sun, Feb 08, 2004 at 07:18:38PM +, Smylers wrote: The Cpan rating thing may help somewhat in this regard -- I will log on and give MIME::Lite a good review sometime, honestly! What would really be useful is a comparison of the various mail-sending modules available, listing which features and interfaces each has and in which situations it can be used -- in the hope that by sticking to facts rather than including opinions it will not be too controversial; perhaps the various module authors could even link to it in each of the modules' docs? I think the CPAN rating system could be of further help here as well. It could be integrated with the search.cpan.org search engine. The rating could appear on the results page, with top-rated modules appearing first. So, just searching for a module named mail should be begin to give you a sensible result. This public prominence would also encourage more people to use the system, I believe. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: New module Mail::SendEasy
* Smylers [EMAIL PROTECTED] [2004-02-05 15:17]: I think the name is unhelpful. ... Then, somehow, I encountered MIME::Lite. It seems to do everything I want and be easier to use than the alternatives, and I use it for all mail-sending. But I'd never've thought to try it in the first place. Yeah, same experience here. But can anybody suggest a better name, one that would suggest to newcomers that this is a good module to use for sending mail? Maybe Mail::Simple? :) I can't believe it's not yet taken, but it ain't. Meanwhile, Mr. Passos has gone ahead and posted Mail::SendEasy under that name. Sometimes I get the distinct impression that his requests for feedback are really little more than attempts at announcing his stuff in one more place. At least this thread spawned some good related discussion. -- Regards, Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: New module Mail::SendEasy
* Orton, Yves [EMAIL PROTECTED] [2004-02-05 15:17]: Mail::Simple? I came up with that independently (ie before seeing your question here), actually, and still think it's the best. Mail::Formally::Known::As::Mime::Lite? Surely that would be Mail::Symbol? -- Regards, Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: New module Mail::SendEasy
Martyn J. Pearce writes: On Wed, Jan 28, 2004 at 12:45:28AM +0100, A. Pagaltzis wrote: But I also find MIME::Lite to be a horrible name. It certainly doesn't present the module as a choice when you go through the obvious keywords looking for modules for sending mail. Of course, at this point, MIME::Lite is so well established a name a change is probably going to be more than difficult. I still think it's feasible though, so as the distribution under the new name includes a stub MIME/Lite.pm that just loads the name module. It's never too late to undo mistakes. (Assuming, of course, that people feel the way I do about the module's name.) This person does, in spades. I think the name is unhelpful. A few years ago I happened to use several different mail-sending modules, in different projects or in code instigated by different people. In general they were OK, but none of them stood out as being superior to the others. Then, somehow, I encountered MIME::Lite. It seems to do everything I want and be easier to use than the alternatives, and I use it for all mail-sending. But I'd never've thought to try it in the first place. Even when I first saw the module I assumed it was for creating mime messages with attachments, and since I didn't want to do anything as complicated as attachments I wouldn't need such a complicated module when there were simpler ones available, surely? But can anybody suggest a better name, one that would suggest to newcomers that this is a good module to use for sending mail? Mail::MIME::Lite doesn't really help -- I'd still make the same assumptions about it as I did, and investigate the modules that sound as though they do sending: Mail::Send, Mail::Sender, Mail::Sendmail, Mail::Transport::Send, Mail::SendEasy, Mail::Mailer, ... Smylers
RE: New module Mail::SendEasy
Title: RE: New module Mail::SendEasy I think the name is unhelpful. A few years ago I happened to use several different mail-sending modules, in different projects or in code instigated by different people. In general they were OK, but none of them stood out as being superior to the others. Then, somehow, I encountered MIME::Lite. It seems to do everything I want and be easier to use than the alternatives, and I use it for all mail-sending. But I'd never've thought to try it in the first place. Even when I first saw the module I assumed it was for creating mime messages with attachments, and since I didn't want to do anything as complicated as attachments I wouldn't need such a complicated module when there were simpler ones available, surely? But can anybody suggest a better name, one that would suggest to newcomers that this is a good module to use for sending mail? Mail::MIME::Lite doesn't really help -- I'd still make the same assumptions about it as I did, and investigate the modules that sound as though they do sending: Mail::Send, Mail::Sender, Mail::Sendmail, Mail::Transport::Send, Mail::SendEasy, Mail::Mailer, ... Well suggest a name. It seems like folks concur that the name is not so great so ill alias it to something else. Mail::Simple? Mail::Sender::Complete Mail::Lite::Not (heh just joking) Mail::Formally::Known::As::Mime::Lite? yves
Re: New module Mail::SendEasy
[EMAIL PROTECTED] (Yves Orton) writes: Well suggest a name. It seems like folks concur that the name is not so great so ill alias it to something else. Mail::Send::MIME? -- People in a Position to Know, Inc.
RE: New module Mail::SendEasy
Title: RE: New module Mail::SendEasy [EMAIL PROTECTED] (Yves Orton) writes: Well suggest a name. It seems like folks concur that the name is not so great so ill alias it to something else. Mail::Send::MIME? Sounds good. Ill go for that. BTW, curses but i still havent found a good name for my dumper. I rue the day you wrote that post about Data::Stream. Yves
Re: New module Mail::SendEasy
* Graciliano M. P. [EMAIL PROTECTED] [2004-01-27 06:16]: First, I didn't know MIME::Lite until Orton send me an e-mail in this list. Of all the things that bother me in this discussion, this one bothers me the most. The reason for this, I think, is two-fold. Obviously Gracilliano's research for prior art was less than conclusive. I often get the impression that he's a little too enthusiastic about making new wheels. But I also find MIME::Lite to be a horrible name. It certainly doesn't present the module as a choice when you go through the obvious keywords looking for modules for sending mail. Of course, at this point, MIME::Lite is so well established a name a change is probably going to be more than difficult. I still think it's feasible though, so as the distribution under the new name includes a stub MIME/Lite.pm that just loads the name module. It's never too late to undo mistakes. (Assuming, of course, that people feel the way I do about the module's name.) -- Regards, Aristotle If you can't laugh at yourself, you don't take life seriously enough.
RE: New module Mail::SendEasy
Title: RE: New module Mail::SendEasy I think MIME::Lite isn't in the Module List so the name wasn't peer-reviewed. The peer-review process offered by [EMAIL PROTECTED] certainly isn't perfect, but I do believe it's very valuable. Unless I read the file incorrectly MIME::Lite is indeed in the module list, at least I see it there. Afaik its been in the wild since at least 98, if not earlier. (I dont know the full history, I am only the module maintainer) Also, I believe that MIME::Lite quite likely predates the peer review process, it certainly predates these newfangled root level names like Mail:: and such. I would argue that MIME isnt actually that bad a name. MIME is the protocol for the contents of a mail. Not related to how mails are recieved, stored, searched, or transmitted. The fact that MIME::Lite knows how to talk to modules that know how to transmit is seperate from the fact that it intends to manage MIME content mails. Since a mail need not be MIME there is no reason for it to be called Mail:: or whatever. Anyway, if someone wants to argue that I should put MIME::Lite into a different namespace ill consider it. It wouldnt be too difficult to also have it called Mail::MIME::Lite or whatever. yves
Re: New module Mail::SendEasy
On Thu, Jan 29, 2004 at 12:23:51PM -, Orton, Yves wrote: I think MIME::Lite isn't in the Module List so the name wasn't peer-reviewed. The peer-review process offered by [EMAIL PROTECTED] certainly isn't perfect, but I do believe it's very valuable. Unless I read the file incorrectly MIME::Lite is indeed in the module list, at least I see it there. Afaik its been in the wild since at least 98, if not earlier. (I dont know the full history, I am only the module maintainer) Ah, thanks. I'd missed it. (And I wish search.cpan.org made it easier to tell if a module is registered). Also, I believe that MIME::Lite quite likely predates the peer review process, it certainly predates these newfangled root level names like Mail:: and such. There's always been a review process for the Module List. But it's always hard to look several years into the future when trying to see how namespaces might evolve. Tim. I would argue that MIME isnt actually that bad a name. MIME is the protocol for the contents of a mail. Not related to how mails are recieved, stored, searched, or transmitted. The fact that MIME::Lite knows how to talk to modules that know how to transmit is seperate from the fact that it intends to manage MIME content mails. Since a mail need not be MIME there is no reason for it to be called Mail:: or whatever. Anyway, if someone wants to argue that I should put MIME::Lite into a different namespace ill consider it. It wouldnt be too difficult to also have it called Mail::MIME::Lite or whatever. yves
RE: New module Mail::SendEasy
Title: RE: New module Mail::SendEasy Unless I read the file incorrectly MIME::Lite is indeed in the module list, at least I see it there. Afaik its been in the wild since at least 98, if not earlier. (I dont know the full history, I am only the module maintainer) Ah, thanks. I'd missed it. (And I wish search.cpan.org made it easier to tell if a module is registered). Indeed. I also wish CPAN.pm made it easier to search for and install unlisted modules. Also, I believe that MIME::Lite quite likely predates the peer review process, it certainly predates these newfangled root level names like Mail:: and such. There's always been a review process for the Module List. Really? Ok, my apologies. But it's always hard to look several years into the future when trying to see how namespaces might evolve. I think that the issue here is that there has been an evolution as to how we think namespaces. MIME:: seems to be named at the implementation level. Its for stuff that does MIME manipulation. Mail:: seems to be named at the functional level. Its for stuff that does emails. These are two totally different philosophies I would say. And personally I think the former makes more sense. Consider a module like Net::SMTP. If it was named at the functional level it would probably be called Email::Transport or something. But personally I think Net::SMTP makes much more sense. It implements the Net:: prototcol SMTP. Should a new protocol come out we wouldnt be modifying Net::SMTP as we would probably have to modify Email::Transport, we would simply add a new module to libnet like Net:SFNMTP (Some Funky New Mail Transport Protocol[tm]) :-) Yves
Re: Fwd: Re: New module Mail::SendEasy
* Mark Overmeer [EMAIL PROTECTED] [2004-01-29 02:12]: But of course, he feels the need to insult other people's work to promote his own. It's his way of gaining importance. I don't think he's insulting in order to promote so much as simply being vocal about his dissatisfaction with existing wheels. He could certainly have done with a calmer tone, though, and I can definitely see how someone being the target of such criticism would not take kindly to it. Unfortunately I really know nothing about either Mail::Box, even though I have looked at it before. From that looking, however, I would say it's easy to see how someone could perceive it as overengineered. Whether that's necessary is a matter of perspective. Simon could have pointed out the negatives and even voiced his opinion without stating his judgement as absolute. Sometimes complexity is called for -- he even mentions Email::Simple is a 9 times out of 10 solution. On the other hand, it's obvious you're quite attached to your overall design. Personally, I think the truth probably lies somewhere in the middle ground. All the modules I've grown really fond of offer a simple way to get the 9 cases out of 10 out of the way but *can* reveal more complexity if desired or necessary. From what I gathered, both Mail::Box and Email::Simple fail this principle -- either on one end of the complexity scale or the other. -- Regards, Aristotle If you can't laugh at yourself, you don't take life seriously enough.
RE: New module Mail::SendEasy
Title: RE: New module Mail::SendEasy But my point is not to rag on about Mail::Box, or any other mail handling module. It's to write smaller, cleaner, single purpose ones. Hey, Email::MIME came out the other day. Comments welcome. Ill have a look at some point. It will be interesting to compare it with MIME::Lite. Yves
Re: Fwd: Re: New module Mail::SendEasy
Sorry, I'm not on the list, but got this passed on... Date: Mon, 26 Jan 2004 13:49:29 -0600 (CST) Subject: Re: New module Mail::SendEasy On Mon, 26 Jan 2004, Simon Cozens wrote: [EMAIL PROTECTED] (Yves Orton) writes: Besides this is there really any reason for yet another MIME::Lite replacement? Yes, there is, but Mail::SendEasy isn't it. :) See http://simon-cozens.org/draft-articles/email.html for a pretty rant about the current state of mail handling modules. I have looked through this document. It's a pity that Simon never came to one of my talks on YAPCs, to grasp the basic concept of MailBox. He's quite far off. But of course, he feels the need to insult other people's work to promote his own. It's his way of gaining importance. I think your article sort of misses the point. You spend too much time ranting about amount of code and slowness, but I think the _real_ problem with Mail::Box is twofold: Slowness is not an issue at all, for MailBox: the target is quality. It is rarely needed to proces hundreds of messages per second, and if you need that, Mail::Box is not the module of your choice. - Not so great API. The API isn't so bad that I'd call it awful, but it's inelegant and bulky, and definitely doesn't make simple things simple. Then please read the tutorial. It shows how simple things can be done. The main user interface is much like Mail::Internet and MIME::Entity provide: (see one of my papers for a more detailed comparison) use Mail::Message; my $msg = Mail::Message-build ( From = 'me', To = 'you', Cc = [EMAIL PROTECTED] , data = [EMAIL PROTECTED], file = 'attach.html' ); $msg-send(via = 'sendmail'); That's not hard to construct and send a fully RFC compliant multipart message. Please start reading the introduction, if the whole is too hard to understand at once... And certainly when you write a paper about the subject. OTOH, it _does_ do basically everything you'd ever want for mail handling/sending, and if you want to do something complex, it'll do that that. That is one of the differences in concept. I prefer libraries to provide a high level functionality. Processing e-mail correctly is very complicated, and I do not expect everyone to read through the 5 related RFCs. I did that, and it resulted in a quite lot of code... e-mail is more complicated to do correctly that most people think. - This API problems are compounded by the docs, which are too nitty-gritty, and basically treat every method and class as equally important. Since there so many methods and classes, this makes it really hard to find the bit you need. Depends what you have read. POD is not sufficient for such a large module. Did you take a look http://perl.overmeer.net/mailbox/html/ ? The docs also sometimes lack important details (like formats of returned values, like is time UTC, etc.). Some things are not repeated often enough. It's quite hard to write suffient docs, and 50,000 lines of it is apparently not enough. However, in case of 'time' is repeated on many places that it is in the same format as provided by the time command. See `perldoc time' If the docs were revamped to start with a tutotial and overview, I think that would go a long way to improving the distro. Have a look at the website, it's all there. http://perl.overmeer.net/mailbox/ I'd love to see someone work with Mark Overmeer to take the existing Mail::Box code and completely revamp the API. But keep most of the internals, because he's dealt with a _lot_ of the niggling corners of mail handling, and there's no need to reinvent that wheel. I am open for suggestions, and have even a mailinglist for that. Show me some things you want to code (and how simple it should be), and I will show you the elegance of MailBox's interface. But I'm really fed-up by this FUD which Simon spreads. It's unjustified, coming from ignorance and envy.. -- MarkOv drs Mark A.C.J. OvermeerMARKOV Solutions [EMAIL PROTECTED] [EMAIL PROTECTED] http://Mark.Overmeer.net http://solutions.overmeer.net
Re: Fwd: Re: New module Mail::SendEasy
On Wed, 28 Jan 2004, Terrence Brannon wrote: - it seems that instead of volunteers to ease the burden of your API usage/docs, people are trying to pull the rug out from under you by populating the Email::* hierarchy... oh well. I hope you're not including me here. My comments were intended as constructive criticism, not a justification for writing yet another set of email modules, which is something I have basically no opinion on at the moment. I'm obviously not averse to writing YA module that does X (see DateTime) if I think there's a good reason, but that's not necessarily always the right answer to a problem. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Fwd: Re: New module Mail::SendEasy
Mark Overmeer wrote: Mail::Box was designed to start with EVERYTHING which the RFCs specify, and ALL uses I know with e-mail. A very high level library. And that's quite a lot... And therefore suffers all the same problems as other large modules (like Tk) have: they are hard to understand when you start with them. - are you happy that you chose to implement Mail::Box in Perl? Was it a clear favorite in terms of language choice? - was vanilla Perl-OO enough for you? did you consider a prototype-based or role-based or delegation-based approach to implementing Mail::Box. - I am very pleased that such a complete package is available for free. I used it to write a daemon which would be emailed Excel spreadsheets as attachments. I used Mail::Box to strip the attachments and apply a number of business rules to the attachments and then email the sender back a clean sheet (with fixed rows) a dirty sheet (with rejected rows) and the original sheet. For reliable daemon creation, monitoring and automatic restarting I used daemontools as I saw nothing in the Proc:: TLNS that looked useable. - it seems that instead of volunteers to ease the burden of your API usage/docs, people are trying to pull the rug out from under you by populating the Email::* hierarchy... oh well.
Re: Fwd: Re: New module Mail::SendEasy
At 02:12 -0600 1/28/04, Dave Rolsky wrote: On Wed, 28 Jan 2004, Terrence Brannon wrote: I also tend to agree with him that Mail::Box is a bit over-engineered in the OO department. Do you _really_ need _eleven_ classes for Mail::Message::Field, which in turn are presumably used by the _nine_ Mail::Message::Head classes? maybe you should ask him on the Mail::Box mailing list. Well, he's already chimed in on this discussion, so I know he's on this list ;) Yes, but is this list the most appropriate place to discuss Mail::Box? I think the Mail::Box list is more appropriate in that respect. Liz
Re: Fwd: Re: New module Mail::SendEasy
On Wed, 28 Jan 2004, Elizabeth Mattijsen wrote: At 02:12 -0600 1/28/04, Dave Rolsky wrote: On Wed, 28 Jan 2004, Terrence Brannon wrote: I also tend to agree with him that Mail::Box is a bit over-engineered in the OO department. Do you _really_ need _eleven_ classes for Mail::Message::Field, which in turn are presumably used by the _nine_ Mail::Message::Head classes? maybe you should ask him on the Mail::Box mailing list. Well, he's already chimed in on this discussion, so I know he's on this list ;) Yes, but is this list the most appropriate place to discuss Mail::Box? I think the Mail::Box list is more appropriate in that respect. Well, this all started with a discussion of an entirely different module ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Fwd: Re: New module Mail::SendEasy
Mark Overmeer wrote: OTOH, it _does_ do basically everything you'd ever want for mail handling/sending, and if you want to do something complex, it'll do that that. That is one of the differences in concept. I prefer libraries to provide a high level functionality. I just want to give you some constructive criticism on your English. What you mean to write above is: "I prefer libraries to provide a high degree of functionality" When you say high-level functionality, you mean that it does not provide low-level functionality. But Mail::Box provides low-level functionality. Just think of the difference between DBI and Class::DBI. DBI provide low-level database functilonality and Class::DBI provides high-level database functionality. BOTH provide a high-*degree* of database unctionality, meaning that they provide a lot of functionality.
RE: Re: New module Mail::SendEasy
Title: RE: Re: New module Mail::SendEasy Mail::SendEasy can: - Handle automatically SMTP AUTH (very important in this days). - Handles automatically TXT, HTML and attachments. Soo, you don't need to think about multipart, boundary, etc... - Compress multiple attachments in a zip file. - It's an self contained module, soo, it doesn't have dependencies (unless Perl). Note that the idea of this module is to have all this resources, that you can find in different modules in CPAN, in only one module. Er, so what does it do that MIME::Lite 3.01_03 does not? Yves
Re: New module Mail::SendEasy
RE: New module Mail::SendEasyRE: New module Mail::SendEasy I know that already exists a lot of SMTP, AUTH and e-mail senders at CPAN, but no one in one single package. Specially one that doesn't have dependencies, like libnet. Ok, so it doesnt need libnet But why is that an advantage? libnet is core nowadays, and on Activestate Perl has been core for ages (which is where you would expect SMTP to be most heavily used.) Besides this is there really any reason for yet another MIME::Lite replacement? Yves Humm, MIME::Lite need sendmail or some object instance that send e-mails to reaally send an e-mail. MIME::Lite is more to can build the content of your e-mail, what is just a part of all the process to send an e-mail. By the awy, I use Mail::SendEasy in Win32, soo, I can't use sendmail. And we know that the sendmail approach to send e-mails in this days is not the best, specially if you want a resource that is platform independent. Note that I have created Mail::SendEasy to be the handler of the mail system of a framework. Soo, the developer that uses this framework doesn't need, and shouldn't, care about how the e-mail is sent. It just write the e-mail. Also it handles SMTP AUTH, one of the purposes that I have wrote it, since our main Web Hoster, for security, need authentication to can send e-mails. Well, as you can see, the main purpose is to have all this resource in one self contained package. Regards, Graciliano M. P.
RE: New module Mail::SendEasy
Title: RE: New module Mail::SendEasy Humm, MIME::Lite need sendmail or some object instance that send e-mails to reaally send an e-mail. Yes thats correct. The composition and transmission layers are logically seperate. But that doesnt change that fact that MIME::Lite is quite capable of using Net::SMTP to transfer mails. And as of 3.01_03 with authentication too. MIME::Lite is more to can build the content of your e-mail, what is just a part of all the process to send an e-mail. Well, not really. Its essentially all you need straight out of the box, given certain platform specific issues. Like libnet on win32, on the presence of something sendmail like on non win32 platforms. By the awy, I use Mail::SendEasy in Win32, soo, I can't use sendmail. And we know that the sendmail approach to send e-mails in this days is not the best, specially if you want a resource that is platform independent. Again, this is merely an question of configuration (also convention, many non sendmail mailers use the same command line arguments). With a single line of code you can use whatever you like for the transmission part of the mail. IMO that good design in fact. There is no hard binding of the two layers. MIME::Lite can use anything that accepts the print method to use for transport. It really doesnt care. So in a sense what you have is two reinvented wheels merged into each other. One, is the composition part of MIME::Lite. Second is one of the many tranmsission schemes available for MIME::Lite to use. Now, my question is this: Why should we assume that your MIME construction is better than MIME::Lites which has been around for practically ever, and has been tested on thousands of machines? Why should we assume that you SMTP implementation is superior to that offered by libnet? Further, how long will you be around? libnet is actively maintained by it author (a respectable member of one of the largest commercial development shops around), MIME::Lite is maintained by me, but if I lose interest it will be pased on, as it was to me. The module has a large enough following already that this is almost guaranteed. I dont say this to be rude or anything, just to make the point. Note that I have created Mail::SendEasy to be the handler of the mail system of a framework. Soo, the developer that uses this framework doesn't need, and shouldn't, care about how the e-mail is sent. It just write the e-mail. Umm, now your saying something different. The developer will HAVE to know about how the mail is sent. He will have to configure the code to use the correct SMTP server, and if he isnt using SMTP will have to configure whatever that is. This would be the same as using MIME::Lite, except that since MIME::Lite uses libnet, as long as the libnet.cfg is configured appropriately about the only thing you have to do is tell MIME::Lite to use SMTP to send, and that requirement only on *NIX systems where SMTP is not the norm. Also it handles SMTP AUTH, one of the purposes that I have wrote it, since our main Web Hoster, for security, need authentication to can send e-mails. Yes. Im aware that this is becomming an ever more common requirement of SMTP servers. Hence MIME::Lite 3.01_03 is dev release of Autheticating SMTP server friendly MIME::Lite. Well, as you can see, the main purpose is to have all this resource in one self contained package. Which doesnt seem like either a good idea, or a real benefit. Transport != Composition. So why should the two be hard bound? Yves
RE: New module Mail::SendEasy
On Mon, 26 Jan 2004, Orton, Yves wrote: Well, not really. Its essentially all you need straight out of the box, given certain platform specific issues. Like libnet on win32, on the presence of something sendmail like on non win32 platforms. FWIW, MIME::Lite has for a long time been my favorite one-stop module for sending mail, with or without attachments. I know it can handle basically everything I need mail-wise, and it just works. All the other modules I've used seem to have various limitations, or bad APIs, etc. Graciliano, I think the Perl community would benefit more if you would contribute to MIME::Lite than create yet another mail sending module. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
RE: New module Mail::SendEasy
Title: RE: New module Mail::SendEasy On Mon, 26 Jan 2004, Orton, Yves wrote: Well, not really. Its essentially all you need straight out of the box, given certain platform specific issues. Like libnet on win32, on the presence of something sendmail like on non win32 platforms. FWIW, MIME::Lite has for a long time been my favorite one-stop module for sending mail, with or without attachments. I know it can handle basically everything I need mail-wise, and it just works. All the other modules I've used seem to have various limitations, or bad APIs, etc. Weeell. I wish I could take credit for some of this, but I cant. Its all Eryq's fault. :-) But seriously, if you are using an authenticating SMTP server, review and comments and bugreports on 3.01_03 would be very welcome. Graciliano, I think the Perl community would benefit more if you would contribute to MIME::Lite than create yet another mail sending module. I agree. But im a touch biased. Gaciliano, should you wish to put some time and effort into MIME::Lite id be happy to work with you to address your concerns. OTOH, _not_ using libnet isnt going to happen in MIME::Lite so if you are hell bent in that direction then I suppose MIME::Lite isnt the right focus. Yves
Re: New module Mail::SendEasy
On Mon, Jan 26, 2004 at 06:05:27PM -0300, Graciliano M. P. wrote: Second, the self contained module counts a lot for me and the framework that we develope! We really can't ask to the user to install soo many modules to can use it. If the author of MIME::Lite is interested to change it's MIME::Lite architecture (just talking about dependencies) I will be interested to add some resources to it, since as I can see now, is a popular module. I'm als a user and fan of MIME::Lite. Perhaps there is an easy way to create an alternate distribution of it that contains all its dependencies, but is easily installable. That seems like a good solution to me. Mark
RE: New module Mail::SendEasy
Title: RE: New module Mail::SendEasy If the author of MIME::Lite is interested to change it's MIME::Lite architecture (just talking about dependencies) I will be interested to add some resources to it, since as I can see now, is a popular module. I'm als a user and fan of MIME::Lite. Perhaps there is an easy way to create an alternate distribution of it that contains all its dependencies, but is easily installable. Hmm, so you mean bundle libnet with MIME::Lite and Mail::Address and MIME::Types and MIME::Base64? Its doable. Actually its more than doable, ive done it here at work. But its not my preference at all. The first and last are perfect examples. Does it make sense to bundle these if on later version of Perl they are core? What about bug fixes etc? Also, for libnet, what about the fact that most *nix users will want to send via sendmail or clone... So all that libnet stuff would be a bit of a waste for them wouldnt it? But I suppose if people wanted it I could look into releasing such a beast. Yves
Re: New module Mail::SendEasy
Dave Rolsky: I think your article sort of misses the point. ... No, I think you miss my point. The slowness and amount of code are not nearly as important as the fact that the API is inelegant. However, the code is slow and bulky. But keep most of the internals, because he's dealt with a _lot_ of the niggling corners of mail handling, and there's no need to reinvent that wheel. There is a need to reinvent it. The wheel is square. The code is slow and bulky, and it is extremely buggy. I spent literally hours of my life last year working around bugs in Mail::Box. The fact that the API is horrible is a function of the fact that it's turned out be a leaning tower of OO Pisa, with slow and bulky code. But my point is not to rag on about Mail::Box, or any other mail handling module. It's to write smaller, cleaner, single purpose ones. Hey, Email::MIME came out the other day. Comments welcome. -- Um. There is no David conspiracy. Definitely not. No Kate conspiracy either. No. No, there is definitely not any sort of David conspiracy, and we are definitely *not* in league with the Kate conspiracy. Who doesn't exist. And nor does the David conspiracy. No. No conspiracies here. - Thorfinn, ASR
