Subject: Re: [lemonade] Determining the "has attachment" status of a message

From: Randall Gellens <[email-masked]>
Date: Sun, 9 Mar 2008 13:43:10 -0800

At 12:50 PM +0100 2/9/08, Philip Van Hoof wrote:

>  Problem:
>
>  When you want to retrieve the envelope of messages you want, on a mobile
>  with limited bandwidth capacity, to do this with a query that has a
>  small amount of columns to avoid consuming a lot of bandwidth.
>
>  If you'd only need to request bodystructure just to know whether or not
>  you have attachments, then for just that one-bit sized flag you'd
>  require the user to perform an IMAP query that is significantly larger
>  than necessary (in bandwidth size, therefore costing real money for the
>  application's user when doing this over for example GPRS).

I'm confused: why would you want to request 
bodystructure *just* to know if the message has 
an attachment (for whatever that means)?  You 
want to display some kind of icon for the 
message, OK, but surely you're going to be 
fetching other information as well (minimal 
headers at least, likely size).  And then what? 
Is this an off-line client that only fetches 
messages on request?  If so, the size is probably 
a more useful hint to the user than an arbitrary 
attachment icon.

At 12:11 PM +0100 2/11/08, DINH Viêt Hoà wrote:

>  To avoid the first expensive request, you can avoid doing that first
>  expensive request.
>  For example, you could fetch only the n most recent messages (people's
>  usual interest)
>  and fetch the others when the user requests them (see iPhone user
>  interface for Mail for reference).

Yes, exactly.  When initially syncronizing a new 
mailbox, don't do it all at once.

At 10:01 PM -0700 2/25/08, Philip Guenther wrote:

>  What is a client supposed to do with a has-attachment indication that may,
>  from the client's point of view, suffer from both false negatives and
>  false positives?  Why bother asking if for something when you can't
>  reliably use the result?

More basically: what is the client supposed to do 
with the has-attachment indicator anyway?  Or, 
more fundamentally, what does the client 
developer expect the user to do?

If the user is expected to base fetch-or-not 
decisions, more information is needed, such as 
size of non-attachment components of the message, 
types of attachments, and so on.  Furthermore, is 
the client going to fetch everything or nothing, 
or is the client going to fetch the 
non-attachment body parts first, perhaps plus 
smallish attachments, and only fetch large 
attachments on request?  If so, then you need 
bodystructure anyway.

At 9:53 AM -0500 2/26/08, Cyrus Daboo wrote:

>  And over time clients may want to have an even more sophisticated indicator
>  of message types beyond just has-attachment. e.g. in Mulberry it can
>  display an attachment icon that is "badged" with addition detail for
>  "styled text message" (contains a text/html alternative), "signed message"
>  (multipart/signed), "encrypted message" (multipart/encrypted), "calendar
>  component" (contains a text/calendar). All of that is done by fetching the
>  BODYSTRUCTURE and doing a client-side analysis.

And is a good way to do it, too.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The first ninety percent of the task takes ninety percent of
the time, and the last ten percent takes the other ninety percent.
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade