[Chandler-dev] attachments vs. multipart-alternative

Jeffrey Harris jeffrey at osafoundation.org
Thu Jun 14 14:16:47 PDT 2007

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!


More information about the chandler-dev mailing list