Subject: RE: [lemonade] Alternate Solution to MobileMailSynchronizationOptimization

From: [email-masked]
Date: Sun, 7 Nov 2004 19:09:06 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of ext Stephane Maes
> Sent: Sunday, November 07, 2004 2:49 PM
...
> I do not share that view. They are proposed improvement to 
> IDLE. However IDLE poses significant problems for mobile e-mail:
> - client battery life and processing reqs

Please provide more detail here. I can not take this at face value
until I understand the details.

CHECKPOINT/CLEARIDLE can support a disconnected model as well as 
a highly connected model.

In the end the only way you will get "quasi-real-time" response 
behavior at the client is to have a highly connected model.

> - server scalability (open port per IDLE client! + queuing)

I don't see the port consumption as an issue. Please explain
why you think this is a problem?

I agree the queuing is something that should be discussed.
The draft goes to great pains to allow queues to be short-lived
and "self-cleaning". The server queues are only a problem if 
statistically they reach a certain level that differs for each
server. I would appreciate comments from others on this.

In general, the scalability answer for IMAP is to split into
multiple IMAP servers. No? 

> - overall efficiency.

Please explain?

> 
> We should not confuse improving IDLE vs addressimng the 
> problem and use cases of mobile e-mail. I am less and less 
> incline to using IDLE even as a sample option in P-IMAP.

The alternates to IDLE in P-IMAP are "in-response" and "out-band". 
The first is just what we have today. The second is moved out side
the scope of IMAP, which basically means we are not solving the
problem.

This is not adequate for my needs.

Mike

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

---

From: Mark Crispin <[email-masked]>
Date: Sun, 7 Nov 2004 21:37:23 -0800 (PST)

> why you think this is a problem?

As a server developer, I don't see port consumption as an issue; nor has 
it been an issue since TCP replaced NCP in 1983.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.