[Chandler-dev] attachments vs. multipart-alternative
jeffrey at osafoundation.org
Thu Jun 14 14:16:47 PDT 2007
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
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!
More information about the chandler-dev