Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Fileupload] Progress bar
Date: Wed, 24 Dec 2003 08:46:05 -0500
Message-ID: <9C5166762F311146951505C6790A9CF8013DF955@US-VS1.corp.mpi.com>
Thread-Topic: [Fileupload] Progress bar
Thread-Index: AcPJmVzT2cD+m8UeTT2Z33H+r4hYiAAPC5VAABOlURA=
From: "Shapira, Yoav" <Yoav.Shapira@mpi.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>


Howdy,

>It sounds like you might have read the posts on tomcat-dev where I
suggest
>adding a ServletStreamListener interface to the servlet API. Since
>implementation of this interface is optional by servlet container use=
rs
(as
>all listener implementations are), wouldn't it be more appropriate to=

do
>something that small and contained rather than what seems to be a
rather
>enormous undertaking ("create ... a low level server API abstraction
...
>perhaps even having a couple of implementations that explore using
>asynchronous IO via the NIO calls in J2SE 1.4")?

It's not small and contained for the container writers who have to
support that listener.  As we already discussed on tomcat-dev, that
would be extremely difficult to do in a performant manner.  And JavaDo=
c
isn't enough to help here.

>I'm not sure there's even been community demand for a low-level API
like
>the one you pointed out, but there certainly has been lots of demand
(in my
>experience) for a means of reliably obtaining a live count of "bytes
>read/bytes written" to/from the i/o streams.

There's been more demand for a low-level API as described by Craig tha=
n
for a live count of bytes in the servlet API, by far, in my experience=
.
As Craig said, the servlet API is designed to be a higher abstraction,=

and consequently most developers who use it don't want to mess with th=
e
low-level details (in fact, most are very happy they don't have to kno=
w
about them).

Yoav Shapira


This e-mail, including any attachments, is a confidential business com=
munication, and may contain information that is confidential, propriet=
ary and/or privileged.  This e-mail is intended only for the individua=
l(s) to whom it is addressed, and may not be saved, copied, printed, d=
isclosed or used by anyone else.  If you are not the(an) intended reci=
pient, please immediately delete this e-mail from your computer system=
 and notify the sender.  Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org