Reviewing EmailSender Component

[John Simons]

Question for anyone that has been involved with the development of EmailSender Component.

I'm currently reviewing the source code doco, and also writing new doco for the web site, so that this component can be released.

In regards to Message, MessageAttachment and MessageAttachmentCollection classes,
the Message class summary documentation tag describes the Message class as "Abstracts an e-mail message".

Maybe I'm not seeing the whole picture yet, but I'm not too sure how are these concrete classes abstracting anything? What are we trying to abstract?

Why not just use the .net classes in System.Net.Mail  (MailMessage, Attachment and AttachmentCollection)?

Does it have anything to do with these classes originally being in System.Web.Mail?

Cheers
John

---

Need a Holiday? Win a $10,000 Holiday of your choice. Enter now..

[John Simons]

What's everyone's view on removing Message, MessageAttachment and MessageAttachmentCollection classes and replacing them with MailMessage, Attachment and AttachmentCollection (the .net framework equivalent)?
Would a patch be welcome?

John

---

From: John Simons <johnsi...@yahoo.com.au>
To: castle-pro...@googlegroups.com
Sent: Sunday, 31 May, 2009 1:49:22 PM
Subject: Reviewing EmailSender Component

[Krzysztof Koźmic]

it all depends of capabilities.

I haven't used email sender, so I'll say what I generally think of
stuff like this.
We generally don't want to duplicate what's already in the framework.
Can all the scenarios be covered by FX classes? Can they easily be
used in every scenario EmailSender is used in?

If yes, than +1: go ahead.

2009/6/7 John Simons <johnsi...@yahoo.com.au>:

[Colin Ramsay]

Well look, there must have been some reason for introducing these classes - do we know what that reason was? Removing them is going to break quite a bit of code (mine included!) - would it be better to just deprecate their use?

2009/6/7 Krzysztof Koźmic <krzyszto...@gmail.com>

[Jonathon Rossi]

I would have thought they were created to provide better classes compared to the .NET 1.1 mail ones.

2009/6/7 Colin Ramsay <colin...@gmail.com>

--
Jono

[Colin Ramsay]

That would make sense, and in that case they're definitely a relic and their use should be discouraged.`

2009/6/7 Jonathon Rossi <jo...@jonorossi.com>

[John Simons]

The CLR classes seem to cover all the requirements of the existing classes, the code actually uses our classes as a proxy to the CLR ones.
In regards to the amount of work, I've started it and so far it has taken me about 30min to patch Monorail project and Email Sender, I still have to update the samples and mark "Ignore" on some of the unit tests of EmailSender.

Colin,
I've thought about deprecating it, but I'm strongly against it, the reason being is that the product hasn't been released yet(I'm talking about v1.0) and that is what I am aiming for.
Also, updating existing code won't take very long time (change Message to EmailMessage).

John

---

From: Colin Ramsay <colin...@gmail.com>
To: castle-pro...@googlegroups.com
Sent: Sunday, 7 June, 2009 11:24:38 PM
Subject: Re: Reviewing EmailSender Component

[John Simons]

Patch submitted: http://support.castleproject.org/projects/COMP/issues/view/COMP-ISSUE-90

On May 31, 1:49 pm, John Simons <johnsimons...@yahoo.com.au> wrote:
> Question for anyone that has been involved with the development of EmailSender Component.
>
> I'm currently reviewing the source code doco, and also writing new doco for the web site, so that this component can be released.
>
> In regards to Message, MessageAttachment and MessageAttachmentCollection classes,
> the Message class summary documentation tag describes the Message class as "Abstracts an e-mail message".
>
> Maybe I'm not seeing the whole picture yet, but I'm not too sure how are these concrete classes abstracting anything? What are we trying to abstract?
>
> Why not just use the .net classes in System.Net.Mail  (MailMessage, Attachment and AttachmentCollection)?
>
> Does it have anything to do with these classes originally being in System.Web.Mail?
>
> Cheers
> John
>

>       Need a Holiday? Win a $10,000 Holiday of your choice. Enter now.http://us.lrd.yahoo.com/_ylc=X3oDMTJxN2x2ZmNpBF9zAzIwMjM2MTY2MTMEdG1f...

[Colin Ramsay]

I did wonder if someone would roll out the "it's not 1.0" argument. If a feature has been there for over 18 months and is used by thousands of people in stable applications, it is totally irrelevant what version number it has. Everyone knows that the Castle release strategy was/is horribly broken (though not through the fault of a single person) and you shouldn't make end-users suffer for that. I fully expect this patch to be applied anyway - just another thing contributing to Castle project's death by 1000 cuts.

[Roelof Blom]

In spite of the tone of Colin's criticism I agree mostly with this remarks. I am -1 on the patch because it does not really fix something that's broken and it causes users unnecessary grief.

Colin, regarding your release strategy remarks: please share your ideas on how to radically improve it.

-- Roelof.

2009/6/8 Colin Ramsay <colin...@gmail.com>

[John Simons]

Colin,

Thanks for your comments, this is exactly what I was after. You have reminded me once again that the users should always come first.
And because of that I'll retract this patch and leave the API as it is.
What I'm trying to do (and you also touch on this subject) is to release the EmailSender component, yes I'm talking about releasing it officially.
In regards to version, I was thinking v1.0, should it be?

Back to the subject of releasing Castle projects, I have to agree with you on that subject too. The castle project release strategy is still broken. There was a big push from hammett (Project Status post) on the 17th of Jan and of course the projects split, since than only 2 projects have been released! I know people are busy and this is not their full time work, everyone is in the same boat here, but, come on what is really preventing projects from being released?
As Colin says most of this projects are already and have been in production environments for over 18 months and users are happy and things are working, and a lot of users are using the trunk version.

It is very sad to see Monorail dying a very slow dead by a lot of developers transitioning to the ASP.NET MVC framework, and yes I think it is too late, even so I strongly believe the Monorail framework is far superior to the MS one.

After all of that said, I still enjoy lots being a committer to the Castle projects, it is a lot of fun.

John

---

From: Colin Ramsay <colin...@gmail.com>
To: castle-pro...@googlegroups.com

Sent: Monday, 8 June, 2009 4:52:25 PM