Hi Brian, Thanks for the quick response.
> First alternative types are intended to provide the same information > in the different renderable formats such as HTML, Rich Text, and > Plain Text. While it could be argued that .ics and .eimml are just > different views of the same data, .ics and .eimml are not > *renderable* in Email Clients. I'd argue that text/plain is a step down from the data we're sending (EIMML). If Thunderbird had an XSL pre-processor of XML bodies I think my argument would be stronger (we could make the .eimml render nicely in browsers that way), in the real world I buy that it's a bit of a stretch to think of EIMML as closely analogous to HTML. > I am also concerned about making this > wide a change at this point in the Preview schedule (I am leaving on > June 21st for EuroPython). Sure, not for preview. Perhaps afterwards? Lets pick up this thread again when we're over the hump ;) > Second using the alternative type means the average user will not see > the (ics or eimml) in his or her mail client. This to me is also an > issue. If a non-Chandler user wants to add the Event or Task to > Outlook or ICal, the .ics file will not be accessible. In fact the > user will not even know that an .ics attachment was sent with the > message. I think we'd probably want to continue to add .ics attachments for events. A large fraction of Chandler emails would still have attachments, but I think iCalendar attachments are more recognizable and thus less annoying. I still think having our "normal" emails not have attachments would be a win. I am curious, too, how many people will be bemused to find attachments on their emails sent from Chandler. Hopefully preview will soon give us a group to survey! Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
