Does c-client library support IDLE command from the client side?
Because I dont want to keep checking on the server if a new mail has
arrived or not.

On Sun, 9 Apr 2006, halayli@gmail.com wrote:
> Does c-client library support IDLE command from the client side?
> Because I dont want to keep checking on the server if a new mail has
> arrived or not.

No, c-client does not have client IDLE support.

In this day and age of NAT you do not want to use IDLE. That's because
the NAT mapping is likely to be flushed if the session goes idle for more
than a couple of minutes.

That's why UW imapd gives unsolicited server responses every minute or so
in IDLE mode; it's an attempt to keep NAT mappings alive. Otherwise, too
many people who used IDLE-capable clients were losing their sessions and
thus not being alerted to new mail.

It was just about the time that I finished IDLE support in UW imapd and
was about to add IDLE support to c-client that NAT reared its ugly head in
a massive way. We had *lots* of people complaining about "not seeing new
mail". It turned out that NAT had dropped their connections, and that
shelved any c-client implementation plans for IDLE.

[You have one guess as to which client program these users were using.
Hint: everybody who uses Windows has it on their system, even if they
don't use it. Ready, set, go!]

Consequently, you need to call mail_noop() periodically to ping the
session. I recommend an interval between 90 to 180 seconds; certainly no
more frequent than 60 seconds.

The role of IDLE today is probably limited to mobile devices (cell phones
and the like) where battery considerations dictate that you don't want to
communicate unless necessary. But the mobile device world doesn't use
NAT; or at least not the same kind of NAT that is commonly found in
offices and people's homes.

If you are programming a mobile device, you probably want custom code
specifically designed for mobile devices to do the protocol operations,
and not a general-purpose library such as c-client. You probably also
want to have custom servers whose behavior is optimized for mobile
devices.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

I will be using the imap protocol for news distribution coming from
agencies like reuters afp, ap etc to journalists. I want to inform the
journalist about the news as soon as it comes. The network environment
is controlled. The idea is to send(email) the news as it comes to
specific mailboxes and using my custom client program the journalist
will be able to read the news and get new ones as it arrives.

On Sun, 9 Apr 2006, halayli@gmail.com wrote:
> I will be using the imap protocol for news distribution coming from
> agencies like reuters afp, ap etc to journalists. I want to inform the
> journalist about the news as soon as it comes. The network environment
> is controlled. The idea is to send(email) the news as it comes to
> specific mailboxes and using my custom client program the journalist
> will be able to read the news and get new ones as it arrives.

What you want is a concept called "notifications". As you noted, this is
something that is best done with a "push" type protocol, whereas IMAP is
primarily a "pull" type protocol.

I suggest that you take a look at the work being done in the IETF with
notification protocols, such as the work in the Lemonade Working Group.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Do you think it is a good idea for me to modify c-client and include
IDLE message support since it will be a controlled environment? Because
I had a look at the work you mentioned above, but I think it will take
me time to implement it.

On Sun, 9 Apr 2006, halayli@gmail.com wrote:
> Do you think it is a good idea for me to modify c-client and include
> IDLE message support since it will be a controlled environment? Because
> I had a look at the work you mentioned above, but I think it will take
> me time to implement it.

Given that you're going to sending notifications for multiple mailboxes,
you really want to use a real notification protocol. Otherwise, you will
be effectively implementing a private notification protocol on top of
IMAP.

Also, if you implement IDLE, you'll have to create some sort of coroutine
or other facility in c-client to make it operate asynchronously.
Currently, c-client is synchronous; a function call translates to sending
a protocol operation and then reading some set of protocol responses
ending with a response that terminates the protocol operation.

If you make the function that does IDLE return without waiting for the
response, then you need some mechanism in place when you do any other
operation to send the DONE and exit. You also need to have a thread
running to read the responses while IDLE.

If you make the function not return until the IDLE is done, then you avoid
the threading, but then your application isn't doing anything else unless
you have some sort of callback to a secondary event loop (albeit one that
returns rather than loops). You also need some sort of mechanism (perhaps
in the secondary event loop) to send the DONE. This is how I would do it
since it's much simpler than the other choices.

Otherwise, you have to make the protocol engine be complete asynchronous,
which would definitely entail multiple threads. That would be the best
way from a purely technical/architectural viewpoint, but it's also much
more work. And in the end, I don't think that it would gain much for all
the added complexity.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Please can you define what you mean by "real notification protocol"?

I think I will go for a single thread handling IDLE as you suggested.

On Sun, 9 Apr 2006, halayli@gmail.com wrote:
> Please can you define what you mean by "real notification protocol"?

A protocol specifically designed to do push-type notifications of events.
IMAP is a protocol designed to do pull-type retrieval of message data.

These are two very different tasks. It's better to use a protocol that is
designed for the task, rather than one that is designed for a different
task.

Although IMAP seems to have some "push" type aspects (e.g., the
unsolicited announcement of new messages and flag changes in the
currently-selected mailbox), this is secondary to the main task of IMAP
which is to "pull" message data from a currently-selected mailbox.

You defined your task as the server immediately telling you when there are
new messages in several different mailboxes. This is pure "push".

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.