Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (herse.apache.org: domain of costin@gmail.com designates
 66.249.92.169 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references;
        b=qydckemSidjyYLsxS84PHs6wtrjTt9oE/j8EYlmvTAVKu/X+TlVL1TDhHGZIs+54yJxG3fwDnMFoUAXKqcNK3tkDWss8vo437fdyomx9ugUU9IP5VTCdMNHIoGe/M0Wis2oTGzFV/EjkRriOKS3LKMiirHwVlFT5Wc8+xWrDP5o=
Message-ID: <96e4b5230706161102n7e678fc1k48509e822837c39d@mail.gmail.com>
Date: Sat, 16 Jun 2007 11:02:17 -0700
From: "Costin Manolache" <costin@gmail.com>
Reply-To: costin@apache.org
To: "Tomcat Developers List" <dev@tomcat.apache.org>
Subject: Re: Proposed simplification of CometEvent
In-Reply-To: <467303B9.6020507@hanik.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_84845_15905325.1182016937147"
References: <46681613.4040903@apache.org> <46704E0D.4000708@hanik.com>
	 <96e4b5230706131702s69f1f198s127ab1975d661a88@mail.gmail.com>
	 <467192BF.1050607@hanik.com>
	 <96e4b5230706141433m6fb4221l19fa3f660193993c@mail.gmail.com>
	 <4672B9D5.60804@hanik.com> <4672BD2B.5060809@apache.org>
	 <96e4b5230706151112g26fe7a63ic9234d6b1358325d@mail.gmail.com>
	 <4672E788.6020104@hanik.com> <467303B9.6020507@hanik.com>

------=_Part_84845_15905325.1182016937147
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 6/15/07, Filip Hanik - Dev Lists <devlists@hanik.com> wrote:


correction, should read
> I can implement inputstream.read() to return 0 on both blocking and non
> blocking *Comet events*, (since sockets are always non blocking)


Ok, my mistake - what I really meant to say is:  I am only interested in
Comet if it
behaves similar with non-blocking sockets ( regardless of implementation ),
i.e. read(), write() called inside
a comet servlet will never block.

>From the description so far it seems the sandbox version has this property
and the trunk has
an option to make it blocking ( or so I understood from your comments ).

I'm not familiar with the concept of 'non blocking *Comet events*' - never
heard of an event that
blocks or doesn't block before. If you mean that during a comet event read
will be blocking (
based on config or whatever else ) - I think this is a bad design.

Costin

------=_Part_84845_15905325.1182016937147--