Re: [Evolution] Proposal: Evolution Attachment UI

[Jeffrey Stedfast <fejj novell com>]

On Fri, 2005-06-03 at 12:02 -0600, Srinivasa Ragavan wrote:
> fejj,
>
> First let me clear one thing.
> Im not trying to solve."inline attachment proposal".

I know.

> What i meant was 'a proposal for UI Attachment', continuing the discussions from the proposals from dobey.

by definition, your proposal must be trying to solve a problem. if the
changes you propose are not meant to solve a problem, then why change
anything? :)

you can't solve a problem without first defining what the problem is.

> Im wasnt discussing about "Content-Disposition: inline" in this mail.
> Im discussing about files, that are attached. 

I don't think you understand MIME.

> What you have specified is one specifc problem, that if the two attachments in that case has same name. We 
> can look at that case specifcally.

the case I listed is just scratching the surface. there are likely
numerous problems with the flat list approach.

> I agree that i could be confusing to put two files with same name. But how many ocassion is that scenario 
> gonna occur. We can have a work around to have a string/some context info appended to the file name for 
> display purpose or something else to avoid the confusion. I have specially spoken about the similiar 
> scenarios, but not assumed the same file name every where.
>
> I feel it may not be worth to ignore this idea, for a problem that of how to display what if we have two 
> attachments of same name.

but that's not the only problem.


allow me to list a few more problems:

1. what qualifies a part to be displayed in the icon list rather than
the gtkhtml message display if not the Content-Disposition?

2. for parts shown inline in the mail-display (lets pretend that we've
already established a means for qualifying what MIME parts are shown
inline and which are shown in the icon list; which, afaict, has not
actually yet been established), how will a user save said part? or hide
said part? If there's no button, then you are removing current
functionality.

3. for any part that ends up in the icon-list through whatever
preconceived qualifications, how would a user request that they be shown
inline? what would happen when they did? would the icon be removed from
the list? how would it be shown in the message? the user won't know
where in the message they'd appear, etc etc etc.

4. when message parts are signed, how would this be presented to the
user? Remember that multiparts can also be signed, not just leaf-node
mime parts. if we have the following:

multipart/mixed
  text/plain
  multipart/signed
    multipart/mixed
      text/plain
      image/jpeg
      application/octet-stream
    application/pgp-signature
  multipart/signed
    multipart/mixed
      text/plain
      audio/wav
    application/pgp-signature
  multipart/signed
    video/mpeg
    application/pgp-signature

How would this be displayed? How would a user know which attachment was
signed along with what else?

5. Encrypted mime parts... until a multipart/encrypted part is
decrypted, we can't know what it contains. It may contain a single mime
part or it may contain a multipart with any number of subparts (other
messages and multiparts (possibly even signed or encrypted) included).
How would this be handled?


One of the great things about the way Evolution currently displays
messages is that even in cases where Evo cannot render some mime-type
inline in the display (yet) for whatever reason, the user can clearly
see where the item was meant to appear. Take the following MIME snippet
for example:

Content-Type: multipart/mixed; boundary="foo"

--foo
Content-Type: text/plain

Senator,

...our current battle plan for dealing with aformentioned problem is as
follows:
--foo
Content-Type: application/x-sw-flash; name="deathstar.swf"
Content-Description: reach out and touch someone
Content-Disposition: inline; filename="deathstar.swf"
Content-Transfer-Encoding: base64

<base64 encoded blob>
--foo
Content-Type: text/plain

...as you can see, this method is quite effective.

Yours truely,

D.V.
--foo--


You'll note in the above example MIME structure that the user has used
MIME to insert a shockwave flash animation between 2 parts of a text
message. By displaying this mesage as 1 continuous block of text and
moving the sw-flash attachment into an icon-list, you destroy the
presentation of the original authors message. to me, this is
unacceptable.

However, the current Evo mail-display implementation would show the suer
that the original author intended for there to be a sw-flash animation
between the 2 text parts even tho Evolution is currently unable to
actually render the sw-flash animation.

This type of thing is very important to me.

Jeff

-- 
Jeffrey Stedfast
Evolution Hacker - Novell, Inc.
fejj ximian com  - www.novell.com