Re: New module Mail::SendEasy
On Mon, 9 Feb 2004, Simon Cozens wrote: > [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. Well, there's more to comparing modules than benchmarks, as you well know. Module X may be slowest, but if it's the only module that does what you need then it's probably the best tool for you. For example, DateTime's date math is considerably slower than Date::Calc's. But if you need multiple time zone support _and_ date math, then it's DateTime or nothing, so clearly DateTime is the right choice here ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
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
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
[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
Simon Cozens writes: > [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? That's nice, and reasonably as to what the module does descriptive. I still feel that when faced with it among the plethora of other modules that I listed earlier in this thread I still probably wouldn't've picked it, because mime sounds like something complicated that I don't need to do. But missing "MIME" out of the module name would be odd, since the module definitely does do mime! I don't think it's a problem that can be solved merely by changing the name of the module -- the fact that there are so many (other) mail-sending modules out there means there's bound to be confusion. Modules rarely get removed from Cpan, so as time goes on the problem is likely to get worse: in more and more areas there will be several (arguably too many) competing modules, making it hard for people to spot which one they want. 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? 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). I mention the comparison idea because I've got half-mentally-composed an article discussing the different CGI-parameter-parsing interfaces available in various modules -- I don't really like any of them (including CGI::Lite, of which I'm the maintainer), but they irritate me in different ways and are less-annoying in different circumstances. I'll let you know when it's finished, and try to put it somewhere where it will be of use to somebody wanting to choose a CGI module. Perhaps I'll then do one for mail-sending (or templating, or XML parsing, or dealing with command-line arguments, or ...) -- but if anybody wants to beat me to it in an area where they have experience of a number of modules I won't mind! Smylers
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
* 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
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
[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 > 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
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: Fwd: Re: New module Mail::SendEasy
* Terrence Brannon ([EMAIL PROTECTED]) [040129 00:09]: > 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? Yes. The power of Perl make such a project doable for someone on his/her own... it wouldn't be possible to achieve the same in C or Java in such a short time. IMO, hardware is cheaper than development time. Performance is usually not the problem. > - 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'm not so much into OO terminolgy, but found a nice story on http://www.caddr.com/macho/archives/iolanguage/2003-12/1283.html which states: "Often people use the misnomer 'prototype-based inheritance' when they really mean delegation-based inheritance" The article explains class-based, delegation-based, role-based, and the Reflective Model. I've done Prolog (role based) a very long time ago, but am more naturally attracted to the class module. Java makes the world too obfuscated, IMO, where Perl uses a much simpler syntax. Of course, without any protections... > - I am very pleased that such a complete package is available for free. Thanks > - 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 am not against different implementations: it all have their own use. As long as implementations follow the standards within the limits of their application. -- 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
* 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 > > 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: 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 > 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 09:10:19AM +, Martyn J. Pearce wrote: > 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. If I ever searched for mail box handling (and I > have), I never looked twice at MIME::Lite, because I figured from the name > that it is for MIME-encoded messages, and got attached to the search results > because it mentioned mail as a likely client. 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. Tim.
Re: New module Mail::SendEasy
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. If I ever searched for mail box handling (and I have), I never looked twice at MIME::Lite, because I figured from the name that it is for MIME-encoded messages, and got attached to the search results because it mentioned mail as a likely client. Mx.
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: 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: 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
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
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
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
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: 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
* Terrence Brannon ([EMAIL PROTECTED]) [040128 08:58]: > >And even if you really do need them, is this something that the end user > >needs to be exposed to? > > yes, that's a good point. How to write docs for the developer of the > code versus someone that wants to make common use of it. Mason has a > Component Developer's Guide which shows how to write something for users > versus core developers. Its all a mater of investment: The Mason development is already going on for a longer time, with more people, and even with a real book. MailBox was developed mainly in 2 years in two days a week by one person, who is not a native speaker, providing user support and giving many conference talks about the subject in this same limited time. In this respect, I think that 50,000 lines of documentation is already quite an achievement... an extract of the functionality on a level of "starter" is certainly useful, but I had no time for that yet. Volunteers? -- 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
* Dave Rolsky ([EMAIL PROTECTED]) [040126 23:58]:
> On Mon, 26 Jan 2004, Mark Overmeer wrote:
> > > >- 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.
> > 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/ ?
>
> Yes, but it _still_ by default shows me _every_ module and _every_ method.
Ok... could be done: docs on different "experience" levels. Although, I
haven't seen other large sets of documentation do that. It's easy to
do when you have only 20 methods, but with 1000 it's much harder.
For these things you need books.
> Also, some methods are probably more important than others, but they're
> all just there to be read.
That's why there are also indexed, where methods are grouped on task.
> The other thing I don't like is that I usually have to read many modules
> worth of docs to figure out what I want. I think Simon nails this when he
> talks about how Mail::Internet forces users to call something like
> "$msg->head->get", etc.
The question is: are you programming OO or imperative, or some intermediate
thing. If you want to program OO, you group functionality in Objects and
keep it there. Of course you can make short-cuts in object which have
the other, but when you extend that too much, you get one blur of code.
In this case, I think Mail::Internet is clean. Mail::Box offers a few
other options:
my $field = $msg->head->get('from');
my $field = $msg->get('from');
my @addrs = $msg->from; # already parsed
> Mail::Box has the same problem. If I start by looking at the
> Mail::Message docs, I sometimes have to follow a bit of a twisty path
> through Mail::Header::* or Mail::Body::* to find what I want.
Of course... documentation is never perfect. People complain if there
is not enough, people complain if there is too much. Everyone has his/her
own style. Not everyone has the same education, etc. That's why I invite
everyone to write documentation for MailBox. Don't forget, it's a product
of one person written in 2 years, so especially the docs need some aging.
> The overview is mostly a description of the byzantine class relationships,
> which is something I'd rather _not_ have to know.
Then I think you have missed out the major part of the docs.
> I haven't looked at the slides from the tutorial yet.
Ah. (don't forget the papers which relate to them)
> I've _used_ Mail::Box, as I said. Here's a quick example of something
> that'd be nice:
>
> # figures out what type this is
> my $folder = Mail::Box::Folder->new( path => '...' );
This object is called: the Mail::Box::Manager. It takes care of all
auto-detection and loading of the right classes, but also protects you
from opening the same folder twice. Trying to put this folder factory
code in a folder object itself is very clumpsy, although I have seen
Perl modules do that before.
Folder detection is a different job than managing a folder. That's the
only place in the program where I spend one line extra, simply for OO reasons.
my $mgr = Mail::Box::Manager->new;
my $folder = $mgr->open(...);
> foreach my $msg ( $folder->new_messages )
foreach my $msg ( $folder->messages('!seen')
> {
> # should be smart and give me everything but the main body
> foreach my $att ( $msg->attachments )
Complicated case: what with nested multiparts and rfc822 encapsulated?
Simplification of the situation is one way of making the API simpler,
but cuts-out some users.
foreach my $att ( $msg->parts('RECURSE') )
> {
> ...
> }
>
> # return the header as a nice simple string, no objects, no arrays,
> # nothing fancy
> my $to_line = $msg->header_string('to');
my $to_line = $msg->get('to');
> my $subject_line = $msg->header_string('subject');
my $subject_line = $msg->get('subject');
(probably you prefer to study('') which does field decoding as well.
> # Again, just the body as a string.
> my $body = $msg->body_string;
my $body = $msg->body->string;
Or use stringifation: print $msg->body;
> if ( $msg->body->mime_type->is_html )
if($msg->body->mimeType eq 'text/html')
Which has overloading to be case-insensive, provided by MIME::Types
> {
> ...
> }
> }
>
> See, the above requires very little knowledge of internals, and makes
> simple things such as getting headers, getting the body, looping through
> attachments, and so on easy.
I agree... so just must be happy that it is all provided for already.
MailBox only needs one line more, for cleaness sake. Examples, like
above are in the tutorials.
> 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 _ni
Re: Fwd: Re: New module Mail::SendEasy
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 ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Fwd: Re: New module Mail::SendEasy
Dave Rolsky wrote: I think Simon nails this when he talks about how Mail::Internet forces users to call something like "$msg->head->get", etc. yes, I agree with you. I had to search and search and search to find what I wanted. However, had I looked at the samples directory, there was something there that did just what I needed. 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. And even if you really do need them, is this something that the end user needs to be exposed to? yes, that's a good point. How to write docs for the developer of the code versus someone that wants to make common use of it. Mason has a Component Developer's Guide which shows how to write something for users versus core developers.
Re: Fwd: Re: New module Mail::SendEasy
On Mon, 26 Jan 2004, Mark Overmeer wrote:
> > >- 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.
It wasn't construction I found difficult. I've written an app that uses
Mail::Box to read folders and insert messages into a database. I thought
I had to read way too much just to figure out how to do simple things like
get the body of an attachment, etc.
> > >- 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/ ?
Yes, but it _still_ by default shows me _every_ module and _every_ method.
I really shouldn't have to care much about the delayed/complete/fast
modules, etc. That's just implementation details.
Also, some methods are probably more important than others, but they're
all just there to be read.
The other thing I don't like is that I usually have to read many modules
worth of docs to figure out what I want. I think Simon nails this when he
talks about how Mail::Internet forces users to call something like
"$msg->head->get", etc.
Mail::Box has the same problem. If I start by looking at the
Mail::Message docs, I sometimes have to follow a bit of a twisty path
through Mail::Header::* or Mail::Body::* to find what I want.
Like I said, I think it doesn't do enough to make simple things simple.
> Have a look at the website, it's all there.
> http://perl.overmeer.net/mailbox/
The overview is mostly a description of the byzantine class relationships,
which is something I'd rather _not_ have to know.
This is a problem that occurs throughout the docs. I get way too much
info on how things are implemented, and not enough abstraction.
I haven't looked at the slides from the tutorial yet.
> 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.
I've _used_ Mail::Box, as I said. Here's a quick example of something
that'd be nice:
# figures out what type this is
my $folder = Mail::Box::Folder->new( path => '...' );
foreach my $msg ( $folder->new_messages )
{
# should be smart and give me everything but the main body
foreach my $att ( $msg->attachments )
{
...
}
# return the header as a nice simple string, no objects, no arrays,
# nothing fancy
my $to_line = $msg->header_string('to');
my $subject_line = $msg->header_string('subject');
# Again, just the body as a string.
my $body = $msg->body_string;
if ( $msg->body->mime_type->is_html )
{
...
}
}
See, the above requires very little knowledge of internals, and makes
simple things such as getting headers, getting the body, looping through
attachments, and so on easy.
AFAIK, none of those things can be done with Mail::Box as easily as I show
above. BTW, all of those operations are things I do in the code I wrote
which uses Mail::Box. But the actual code is signficantly more complex.
> But I'm really fed-up by this FUD which Simon spreads. It's unjustified,
> coming from ignorance and envy..
I doubt it comes from ignorance or envy.
However, as usual, Simon's manner is far more irritating than it needs to
be, and I think you're justified in being angry at him.
Nonetheless, I think his points about API design are correct. Here's the
key phrase in his article, IMO:
This is quite a shame, because mail handling as an abstract concept is
very simple indeed. Nine times out of ten, you want to look at a piece of
mail, get or set some of its headers, and look at its body.
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?
And even if you really do need them, is this something that the end user
needs to be exposed to?
-dave
/*=
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
Re: New module Mail::SendEasy
On Mon, Jan 26, 2004 at 02:25:19PM -0600, Dave Rolsky wrote: > On Mon, 26 Jan 2004, Orton, Yves wrote: > > > But I suppose if people wanted it I could look into releasing such a beast. > > Or Graciliano could just include with the app he's distributing. That > makes a lot more sense. That's more what I want it mind. The MIME::Lite standard distribution would be unaffected, but another option would be available, at least for this one use. Isn't this kind of packaging sort of what the "PAR" project is about? http://www.perladvent.org/2003/25th/ 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
On Mon, 26 Jan 2004, Orton, Yves wrote: > But I suppose if people wanted it I could look into releasing such a beast. Or Graciliano could just include with the app he's distributing. That makes a lot more sense. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
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
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
> > 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. > First, I didn't know MIME::Lite until Orton send me an e-mail in this list. 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. Note that the main approach when I was developing Mail::SendEasy was the send part, not the build of a MIME message, since MIME::Lite can handle more things. Regards, Graciliano M. P.
RE: New module Mail::SendEasy
Title: RE: New module Mail::SendEasy > - 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. > 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. On this note, I was thinking of providing some "short cut" procedures for MIME::Lite to make simple things even simpler. I also tweaked it in 3.01 to make things a bit more intuitive for Win32 users, such as defaulting to SMTP transport when on that platform. Im always open to new ideas about improving the API of MIME::Lite, so long as the hysterical stuff is handled too. Im hoping that what I did in 3.01_03 lives up to that. I dont know though. yves
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 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: - 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. 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. - 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. The docs also sometimes lack important details (like formats of returned values, like is time UTC, etc.). If the docs were revamped to start with a tutotial and overview, I think that would go a long way to improving the distro. The slowness and amount of code are not nearly as important as the fact that the API is inelegant. This was a big concern of mine with the DateTime code. I _hope_ that whether or not it's lots of code (which it is) and slow (which it can be), that at least the API is easy enough to learn that it makes doing simple things simple. OTOH, if you want to do something really complex, you can. And most importantly, it handles all the niggling little corner cases, and it (modulo bugs ;) does everything correctly. 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. -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
[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. -- Thus spake the master programmer: "After three days without programming, life becomes meaningless." -- Geoffrey James, "The Tao of Programming"
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 > 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
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 > 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
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: Re: New module Mail::SendEasy
> * Graciliano M. P. [2004/01/24 18:26]: > > "Mail::SendEasy - Send plain/html e-mails through SMTP servers > > (platform independent). Supports SMTP authentication and attachments." > > > > 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. > > Sounds a lot like Mail::Sendmail, except for the HTML part. How is > Mail::SendEasy different from Mail::Sendmail? > After take a look at Mail::Sendmail, and it's source, I can tell you the differences: 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. Regards, Graciliano M. P.
