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 <[email protected]> To: [email protected] Sent: Monday, 8 June, 2009 4:52:25 PM Subject: Re: Reviewing EmailSender Component 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. On Mon, Jun 8, 2009 at 2:23 AM, John Simons <[email protected]> wrote: 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 <[email protected]> To: [email protected] Sent: Sunday, 7 June, 2009 11:24:38 PM Subject: Re: Reviewing EmailSender Component That would make sense, and in that case they're definitely a relic and their use should be discouraged.` 2009/6/7 Jonathon Rossi <[email protected]> I would have thought they were created to provide better classes compared to the .NET 1.1 mail ones. 2009/6/7 Colin Ramsay <[email protected]> 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 <[email protected]> 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 <[email protected]>: > 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 <[email protected]> > To: [email protected] > Sent: Sunday, 31 May, 2009 1:49:22 PM > Subject: Reviewing EmailSender Component > > 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.. > > > ________________________________ > Need a Holiday? Win a $10,000 Holiday of your choice. Enter now.. > > > -- Jono ________________________________ Need a Holiday? Win a $10,000 Holiday of your choice. Enter now.. Need a Holiday? Win a $10,000 Holiday of your choice. Enter now.http://us.lrd.yahoo.com/_ylc=X3oDMTJxN2x2ZmNpBF9zAzIwMjM2MTY2MTMEdG1fZG1lY2gDVGV4dCBMaW5rBHRtX2xuawNVMTEwMzk3NwR0bV9uZXQDWWFob28hBHRtX3BvcwN0YWdsaW5lBHRtX3BwdHkDYXVueg--/SIG=14600t3ni/**http%3A//au.rd.yahoo.com/mail/tagline/creativeholidays/*http%3A//au.docs.yahoo.com/homepageset/%3Fp1=other%26p2=au%26p3=mailtagline --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en -~----------~----~----~----~------~----~------~--~---
