Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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.