commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "jerome lacoste" <>
Subject Re: [FILEUPLOAD] RfC: Proposed API changes for streaming
Date Sat, 17 Jun 2006 05:20:14 GMT
On 6/16/06, Jochen Wiedmann <> wrote:
> wrote:
> > As I understand it, by the time you call getInputStream(), the user's POST
> > request is already entirely in the server's memory space, or it has been
> > written to disk. This data isn't consumed when you read() it, so why can't
> > you get another InputStream over it?
> No. At the time when getInputStream() is called, the request data is read up
> to the beginning of the file, or form field. The InputStream returns the
> file, or form field, after which the request data is positioned at the end
> of the file, or form field.

(Caution I am not familiar with the original code. Just read that thread).

To me it sounds like SlimFileItem is implying that getInputStream() is
doing some kind of iterator side effect.

First if kept like this, it probably shouldn't be a getter, maybe
inputStream(). Also it makes wonder if the separation between the
iterator and the iterator item is done at the right place. Think about
JDBC or Collection. This proposal is not intuitive.

Second "while SlimFileItem should throw an IllegalStateException on
the second invocation".

"Should throw" as part of an interface implies that FileItem does not
respect the spec of its base class. "May throw" sounds better.

Also the above sentence sounds classish not interfaceish (i.e. reading
it makes it sound like SlimFileItem is a class not an interface).

Finally, "FileBaseUpload would be changed to use getItemIterator
internally and convert the SlimFileItem instances into FileItem."

I don't particularly like down castings. That ties the class to the
particular implementation. What does this hide?



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message