async pop protocol
[1/5] from: rotenca::telvia::it at: 23-Sep-2003 13:46
I'm writing an async pop protocol. I have many doubts about its user
interface. Any ideas about this?
---
Ciao
Romano
[2/5] from: antonr:iinet:au at: 25-Sep-2003 3:10
What does it offer that is different to usual pop scheme?
I imagine a situation where the handler notifies your
call-back function when there is an email ready.
Call-back might want to handle chunks of data rather
than a cached email, so a direct mode would be good.
So the handler should communicate with the call-back
via a simple dialect. Something like this:
'data-ready
'command-result (ie. from LIST
'full-email
'start-email
'chunk
followed by the data...
I think the simplest case should do as much as possible automatically:
(log in, LIST, retrieve all emails into a block result, log out),
using as little dialect as possible, and direct mode should
give full control, allowing to preview mail headers using TOP,
filter undesirable mails, specify filenames for emails, etc.
I presume you will call it async-pop:// ?
Anton.
[3/5] from: rotenca:telvia:it at: 25-Sep-2003 21:52
Hi Anton,
> What does it offer that is different to usual pop scheme?
>
> I imagine a situation where the handler notifies your
> call-back function when there is an email ready.
Yes.
> Call-back might want to handle chunks of data rather
> than a cached email
I am for a block of 1 or more emails.
> I think the simplest case should do as much as possible automatically:
> (log in, LIST, retrieve all emails into a block result, log out),
my doubts:
1) the retrieving of mails should start soon after the open or after a comand
( which command)?
2) now i bufferize all mail on servers (no /direct mode), can it be a big
problem?
> give full control, allowing to preview mail headers using TOP,
I use a mode "TOP" or "RETR"
open: pop-async://blablabla/top/5
it can be changed after open with:
insert port "top 5"
insert port "retr"
> I presume you will call it async-pop:// ?
or pop-async:// ??
---
Ciao
Romano
[4/5] from: gchiu:compkarori at: 26-Sep-2003 16:29
On Tue, 23 Sep 2003 13:46:42 +0200
"Romano Paolo Tenca" <[rotenca--telvia--it]> wrote:
>I'm writing an async pop protocol. I have many doubts
>about its user
>interface. Any ideas about this?
Romano,
Would you be able to expand on what your ideas are on how
this would work?
--
Graham Chiu
http://www.compkarori.com/vanilla/
[5/5] from: antonr:iinet:au at: 27-Sep-2003 2:21
Romano,
> > Call-back might want to handle chunks of data rather
> > than a cached email
>
> I am for a block of 1 or more emails.
Sounds good.
> > I think the simplest case should do as much as possible automatically:
> > (log in, LIST, retrieve all emails into a block result, log out),
>
> my doubts:
>
> 1) the retrieving of mails should start soon after the open or
> after a comand
> ( which command)?
How about RETR ? Seems pretty clear to me.
Do you mean like:
open: pop-async://blabla/retr/auto
(That would do everything as fully automatic as possible).
?
> 2) now i bufferize all mail on servers (no /direct mode), can it be a big
> problem?
Do you mean protocol waits until all mail is downloaded into memory,
then delivers a big block of mails in one go?
That's alright.
I would be happy if it's buffered as long as I know there is a
/direct mode allowing email-by-email and also chunk-by-chunk
download coming soon. :)
Perhaps a max size could be specified (like 10MB for instance),
emails larger than this size would be downloaded using a specified
disk cache file in /direct mode.
I would like the following degrees of control:
1) Fully automatic, buffer everything,
good if all your emails are rebol-list mail only :)
2) Notify as each mail finishes downloading
3) Notify as each chunk of data comes down
4) Notify on a regular schedule, no matter what the situation is,
tell the user what the protocol state is.
That's roughly in order of granularity, from less detail to more detail,
though you could have different combinations of some notifications.
This makes me think of a feature request:
Order the mail in order of increasing size before downloading,
so you get lots of small mails quickly (which gives a good
user interface feedback) and can start reading straight away while
the larger emails are still downloading.
Shouldn't forget the original order though :)
How about:
open pop-async://blablabla/retr/order [decreasing size]
> > give full control, allowing to preview mail headers using TOP,
>
> I use a mode "TOP" or "RETR"
>
> open: pop-async://blablabla/top/5
>
> it can be changed after open with:
>
> insert port "top 5"
> insert port "retr"
That's good.
> > I presume you will call it async-pop:// ?
>
> or pop-async:// ??
Either is good, use whatever you are using now.
> ---
> Ciao
> Romano
Anton.