You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Corey Scott <co...@gmail.com> on 2004/10/23 10:02:59 UTC
[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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [email] Current status, etc.
Posted by Joe Germuska <Jo...@Germuska.com>.
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
Joe@Germuska.com
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [email] Current status, etc.
Posted by Corey Scott <co...@gmail.com>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [email] Current status, etc.
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
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:corey.scott@gmail.com]
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [email] Current status, etc.
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Corey Scott" <co...@gmail.com>
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [email] Current status, etc.
Posted by Corey Scott <co...@gmail.com>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [email] Current status, etc.
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [email] Current status, etc.
Posted by Stephen Colebourne <sc...@btopenworld.com>.
----- Original Message -----
From: "Matthias Wessendorf" <ma...@matthias-wessendorf.de>
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [email] Current status, etc.
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
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:corey.scott@gmail.com]
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org