On Dec 17, 2003, at 10:48 PM, Mark Crispin wrote:
STATUS is not necessary, and can involve excessive costs. These costs
have nothing to do with new mail. The costs are in STATUS data which,
for
the limited purpose of new mail notification, are frills!
Well, many clients don't really want to kno
On Wed, 17 Dec 2003, Christof Drescher wrote:
> I'd be interested to see your argument for MESSAGES, because I assumed
> some coherence between MESSAGES and EXISTS, which is used to announce
> new mail in selected mailboxes. Or am I off the track again?
The problem is that prior state is implied.
Now we get to a point I fully comply with you :-)
> > Needed: Notification of new mail arrival in unselected mailboxes
>
> Good definition.
>
> Since you only need notification of new mail arrival in unselected
> mailboxes, then the solution should be tightly focused on accomplishing
> that goal.
--On 2003-12-17 12:57 PM -0800 Larry Osterman
<[EMAIL PROTECTED]> wrote:
On NT, 300,000 TCP connections that are idle means that 300,000 socket
handles are open. On *nix, it means that 300,000 processes are
running.
Not a chance. It means one (or a very few) threaded processes are
giving select
Arnt Gulbrandsen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 17, 2003 11:48 AM
To: Larry Osterman
Cc: Christof Drescher; IMAP protocol mailing list; DINH Viet Hoa
Subject: Re: Extension for status updates of non-selected mailboxes?
Larry Osterman writes:
> TCP connections are NOT cheap, and do n
On Wed, 17 Dec 2003, Christof Drescher wrote:
> So what? A server for which it is "expensive" to do this status update -
> don't advertise it in your CAPABILITY and you need not bother coding it.
> Right? Even if you advertise it and for a certain folder it is to expensive,
> give a NO response. Yo
Hi,
in the best tradion of what is to be in the core specs and what should be an
extention, please consider this:
> > One addition would then be the part of an "extension": A command to
supply a
> > list of folders which it wants to receive untagged STATUS updates about.
> >
> > Wouldn't that be a
On Wed, 17 Dec 2003, Christof Drescher wrote:
> One addition would then be the part of an "extension": A command to supply a
> list of folders which it wants to receive untagged STATUS updates about.
>
> Wouldn't that be a really simple solution? Conforming? Rather easy to
> implement on both clien
Answering my own posting may make me look strange, but anyway...
One addition would then be the part of an "extension": A command to supply a
list of folders which it wants to receive untagged STATUS updates about.
Wouldn't that be a really simple solution? Conforming? Rather easy to
implement on
Larry Osterman writes:
TCP connections are NOT cheap, and do not scale infinitely. When you
have 30,000 clients connected to your IMAP server (a very reasonable
number for a large farm), and each of them is opening 10 mailboxes,
you're talking 300,000 sockets in use.
That will tax the limits of
, December 17, 2003 2:56 AM
To: Arnt Gulbrandsen
Cc: [EMAIL PROTECTED]
Subject: Re: Extension for status updates of non-selected mailboxes?
Arnt Gulbandsen wrote:
>TCP connections are cheap, once opened. And even opening can be cheap,
>depending on whether you're using TLS or
--Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Arnt Gulbrandsen
Sent: Wednesday, December 17, 2003 2:34 AM
To: Christof Drescher
Cc: IMAP protocol mailing list; DINH Viet Hoa
Subject: Re: Extension for status updates of non-selected mailboxes?
Christof Dresc
On Wed, 17 Dec 2003, Arnt Gulbrandsen wrote:
> Christof Drescher writes:
> > Anyway: Do you argue such an extension would not be wise to have?
> There have been a great many attempts at this, all failed. I do not feel
> competent to judge why they failed, and how it can successfully be done.
I can
Timo Sirainen wrote:
>I'm not sure if this really needs to be an extension. Rather server
>could just send untagged STATUS updates to client whenever it feels
>like it. Only problem is that most clients seem to ignore it if they
>didn't request it themselves.
You are so right! Thank you!
I really
On Dec 17, 2003, at 1:38 PM, Christof Drescher wrote:
Anyway: Do you argue such an extension would not be wise to have?
20 TCP connections might be cheap for CPU and memory, but it also means
more network traffic which might not be nice if your bandwidth costs
per kilobyte (mobile phones).
I'm
Christof Drescher writes:
Anyway: Do you argue such an extension would not be wise to have?
I'm not sure. It would be a good feature, but is appropriate as an IMAP
extension, or should it be a separate protocol, perhaps using UDP?
There have been a great many attempts at this, all failed. I do no
Hi,
it's not really the point to argue about it, but I code for quite some time
now and - forgive me - sometimes think with the eyes of a "small system"
where RAM is valuable and unnecessary demands at least SHOULD be avoided.
And I like to enhance the software solution rather than putting more
ha
Christof Drescher writes:
Arnt Gulbandsen wrote:
TCP connections are cheap, once opened. And even opening can be
cheap, depending on whether you're using TLS or not and what sort of
authentication you're using.
It might be "cheap" for modern pc systems and only concerning the
Network overhead. B
Arnt Gulbandsen wrote:
>TCP connections are cheap, once opened. And even opening can be cheap,
>depending on whether you're using TLS or not and what sort of
>authentication you're using.
It might be "cheap" for modern pc systems and only concerning the Network
overhead. But for one, there are muc
Christof Drescher writes:
Why not select all the interesting mailboxes to poll (in different
sessions) and NOOP them or use IDLE extension.
Because this creates an enourmous overhead in connections, server
workload etc. Let's assume we have only 10 mailboxes "shared" with a
workgroup of 20 users
Hi,
>> Is there any "simple" way for a client to get notified if a non-selected
>> mailbox has newly arrived mail?
>It seems that you want to poll this mailbox.
Not "poll" in the closer sense, I want an information pushed at new arrival.
>> Possibly best would be an update sent
>> without request
Christof Drescher wrote :
> Is there any "simple" way for a client to get notified if a non-selected
> mailbox has newly arrived mail?
It seems that you want to poll this mailbox.
> Possibly best would be an update sent
> without request, a real notification then (e.g. as a response to a NOOP
>
22 matches
Mail list logo
