RE: [email] Current status, etc.
Hi Corey, I read your mail and saw that you contributed some unit tests. thanks. I am using email in a webapp for sending ecards. That works fine. I submitted two patches for this project, since I got kamar. One allows you do to pop3BeforeSmtp auth. (thanks to Daniel Perry) the other allows you to set a port for STMP server. All patches depend on my needs. the first was created during a discussion in struts user list, second was inside of bugzilla, so I submitted it. However, I start next month a project, that needs email as well and now I am thinking on dealing with XML based configurations. Now the programmer must set user, host etc. If you declare it in xml it is not static build into my app. Any comments? Regards, Matthias -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Saturday, October 23, 2004 10:03 AM To: Jakarta Commons Developers List Subject: [email] Current status, etc. I recently came across this project and noticed that it seems to be very inactive. I must say that this is surprising cause there are few web apps that don't use email is some variation or another. So I have a couple of questions: 1) Are you using this project? 2a) If so, what can be done to improve it? What is annoying about it? 2b) If not, why not? What doesn't it do that stops you from using it? 3) Any other suggestions? All responses will be greatly appreciated. Thanks, Corey Scott PS. It is not my intention to start a flame war, so please be honest but not (too) brutal in any criticism - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] Current status, etc.
- Original Message - From: Matthias Wessendorf [EMAIL PROTECTED] However, I start next month a project, that needs email as well and now I am thinking on dealing with XML based configurations. Now the programmer must set user, host etc. If you declare it in xml it is not static build into my app. Any comments? A project like [email] should not, IMHO, have its own configuration code. That changes it from a low-level library usable by all to one that forces a specific configuration route. This is no good for frameworks like Spring where the configuration mechanism is part of the framework. If you look at commons in general you will find that most commons projects are configured by javabean methods, not by configuration. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Current status, etc.
A project like [email] should not, IMHO, have its own configuration code. That changes it from a low-level library usable by all to one that forces a specific configuration route. This is no good for frameworks like Spring where the configuration mechanism is part of the framework. Jupp, that sounds reasonable. The EmailConfigurator, which I plan is for my own. The customer is more able to change his email settings. not more. (perhaps also I like to play a bit with topics like dependency injection ;-)) For now, [email] works good for me and is handy! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] Current status, etc.
Stephen, Forgive me for asking for confirmation, but does this mean that you are NOT in favor of changing the way that the Email library handles configuration? Meaning that the coder must still set all of the config vars? I think this is fine, in fact I find that I use the config project for this anyway, as config has (IMHO) to be externalized. With all that said, maybe would could make some kind of wrapper or standard set of config vars but make it in such a way that makes it optional? This would probably be a config instance (from the config project) or similar, Matthias does this suit your needs? Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] Current status, etc.
I was actually considering a couple of functions: 1) where by you could input a HTML file and it would parse out all img links and add the cids automatically (obvious problem with image directories here). 2) maybe some small helper functions / wrappers around the existing functions, eg. adding an attach method to the email class itself (basic idea is just improve usablity) Thoughts? Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Current status, etc.
Corey, I haven't looked at [Configuration] project. On my current project I have a solution like: -user's config is in xml I wrote a Configuratore, using Digester, and populating the properties of my UserConfig JavaBean. The JavaBean is used on setting up connection to a Server. Regards, Matthias -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Saturday, October 23, 2004 12:23 PM To: Jakarta Commons Developers List Subject: Re: [email] Current status, etc. Stephen, Forgive me for asking for confirmation, but does this mean that you are NOT in favor of changing the way that the Email library handles configuration? Meaning that the coder must still set all of the config vars? I think this is fine, in fact I find that I use the config project for this anyway, as config has (IMHO) to be externalized. With all that said, maybe would could make some kind of wrapper or standard set of config vars but make it in such a way that makes it optional? This would probably be a config instance (from the config project) or similar, Matthias does this suit your needs? Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] Current status, etc.
From: Corey Scott [EMAIL PROTECTED] Forgive me for asking for confirmation, but does this mean that you are NOT in favor of changing the way that the Email library handles configuration? Meaning that the coder must still set all of the config vars? Exactly. No config system in [email] itself. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] Current status, etc.
At 4:02 PM +0800 10/23/04, Corey Scott wrote: I recently came across this project and noticed that it seems to be very inactive. I must say that this is surprising cause there are few web apps that don't use email is some variation or another. So I have a couple of questions: 1) Are you using this project? 2a) If so, what can be done to improve it? What is annoying about it? 2b) If not, why not? What doesn't it do that stops you from using it? I suspect that a lot of people solved this problem internally before they knew commons-email existed. This is the main reason I haven't started using commons-email in projects. We've developed a pretty elaborate framework for externalizing configuration and managing message templates built around a library which is like commons-email, but which isn't commons-email. Since that works, I haven't been motivated to rewrite the framework to use a different email package. Still, since I've done a fair amount of email code, and since I'm interested in commons packages, I'm trying to at least keep an eye on commons-email discussions. Unfortunately, I've been too busy with my day job to do more than that. I think that it would be good to keep commons-email lean; however, if you have ideas where it can be improved, by all means, suggest them (with patches when possible!) Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
