Subject: [lemonade] Fetching attachments page-by-page

From: <[email-masked]>
Date: Tue, 20 Jun 2006 13:10:39 +0300

Hi all,
I understand that profile references OMA STI for conversion of attachments. OMA STI however does not allow fetching an attachment page-by-page.
However, there are valid use cases (like get only the first two pages of a PPS file and not to download the rest if the user is not interested).
I guess there is no such problem with plain text files (You can just get any number of bytes), however when it's a binary (PDF, PPS, etc), the binary file format be broken when retrieval is based on the number of bytes (some formats include headers, index tables, etc at the end of the file).
So, do You think it is worth working out such mechanism in profile, or we should simply leave the issue alone?
Thank You.

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Tony Finch <[email-masked]>
Date: Tue, 20 Jun 2006 11:50:49 +0100

On Tue, 20 Jun 2006, [email-masked] wrote:

> I understand that profile references OMA STI for conversion of
> attachments. OMA STI however does not allow fetching an attachment
> page-by-page. However, there are valid use cases (like get only the
> first two pages of a PPS file and not to download the rest if the user
> is not interested). I guess there is no such problem with plain text
> files (You can just get any number of bytes), however when it's a binary
> (PDF, PPS, etc), the binary file format be broken when retrieval is
> based on the number of bytes (some formats include headers, index
> tables, etc at the end of the file). So, do You think it is worth
> working out such mechanism in profile, or we should simply leave the
> issue alone?

I think it's too dependent on the details of the media type. If its format
is designed for paged access then byte-range requests should be enough.
This is all that HTTP provides, for example, so it's probably not worth
trying to provide higher-level semantics in IMAP.

PDF is designed to work with byte-range requests, and in fact when I was
fixing Apache's byte-range request handling several years ago, the most
common client that did byte-range requests was the Adobe Acrobat viewer.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
MALIN: SOUTH 4 OR 5 INCREASING 6 TO GALE 8 THEN VEERING WEST, PERHAPS
INCREASING SEVERE GALE 9 LATER. RAIN. MODERATE OR POOR.

---

From: <[email-masked]>
Date: Tue, 20 Jun 2006 14:02:49 +0300

Ok, so You're saying that we should not worry about it because it's not worth it, right?
Sounds fine, just wanted to verify it.
Thank You.

-----Original Message-----
From: Tony Finch [mailto:[email-masked]] On Behalf Of ext Tony Finch
Sent: 20 June, 2006 13:51
To: Ordogh Zoltan (Nokia-TP-MSW/Tampere)
Cc: [email-masked]
Subject: Re: [lemonade] Fetching attachments page-by-page

On Tue, 20 Jun 2006, [email-masked] wrote:

> files (You can just get any number of bytes), however when it's a 
> binary (PDF, PPS, etc), the binary file format be broken when 
> retrieval is based on the number of bytes (some formats include 
> headers, index tables, etc at the end of the file). So, do You think 
> it is worth working out such mechanism in profile, or we should simply 
> leave the issue alone?

I think it's too dependent on the details of the media type. If its format is designed for paged access then byte-range requests should be enough.
This is all that HTTP provides, for example, so it's probably not worth trying to provide higher-level semantics in IMAP.

PDF is designed to work with byte-range requests, and in fact when I was fixing Apache's byte-range request handling several years ago, the most common client that did byte-range requests was the Adobe Acrobat viewer.

Tony.
--
f.a.n.finch  <[email-masked]>  http://dotat.at/
MALIN: SOUTH 4 OR 5 INCREASING 6 TO GALE 8 THEN VEERING WEST, PERHAPS INCREASING SEVERE GALE 9 LATER. RAIN. MODERATE OR POOR.

---

From: Randall Gellens <[email-masked]>
Date: Tue, 20 Jun 2006 11:14:35 -0700

At 1:10 PM +0300 6/20/06, <[email-masked]> wrote:

> page-by-page.
>  However, there are valid use cases (like get only the first two 
> pages of a PPS file and not to download the rest if the user is not 
> interested).
>
>  I guess there is no such problem with plain text files (You can 
> just get any number of bytes), however when it's a binary (PDF, 
> PPS, etc), the binary file format be broken when retrieval is based 
> on the number of bytes (some formats include headers, index tables, 
> etc at the end of the file).
>
>  So, do You think it is worth working out such mechanism in profile, 
> or we should simply leave the issue alone?
>  Thank You.

I think we should not add extra features or complexity if we can 
possibly avoid it.  Keep in mind that new features can always be 
added in the future, requiring only the publication of a document 
extending the specific mechanism involved.  I don't see a compelling 
reason to add this feature at this time.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The solution to a problem changes the nature of the problem.

---

From: <[email-masked]>
Date: Wed, 21 Jun 2006 13:25:13 +0300

Thank You Randall,
no problem - just wanted to hear opinions on it since I could not make it to the interim meeting. 

-----Original Message-----
From: ext Randall Gellens [mailto:[email-masked]] 
Sent: 20 June, 2006 21:15
To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); [email-masked]
Subject: Re: [lemonade] Fetching attachments page-by-page

At 1:10 PM +0300 6/20/06, <[email-masked]> wrote:

>  However, there are valid use cases (like get only the first two pages 
> of a PPS file and not to download the rest if the user is not 
> interested).
>
>  I guess there is no such problem with plain text files (You can just 
> get any number of bytes), however when it's a binary (PDF, PPS, etc), 
> the binary file format be broken when retrieval is based on the number 
> of bytes (some formats include headers, index tables, etc at the end 
> of the file).
>

I think we should not add extra features or complexity if we can possibly avoid it.  Keep in mind that new features can always be added in the future, requiring only the publication of a document extending the specific mechanism involved.  I don't see a compelling reason to add this feature at this time.
--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: --------------- The solution to a problem changes the nature of the problem.