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 <[email protected]> > 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.<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 -~----------~----~----~----~------~----~------~--~---
