Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <26281991.1202895608419.JavaMail.jira@brutus>
Date: Wed, 13 Feb 2008 01:40:08 -0800 (PST)
From: "Jukka Zitting (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (IO-71) [io] PipedUtils
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/IO-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568479#action_12568479 ] 

Jukka Zitting commented on IO-71:
---------------------------------

You're right, my solution suffers from having an unlimited buffer. Personally I don't think that's too much of an issue (all the really troublesome examples I can come up with are highly hypothetical), but I you're right that a thread-based solution is more robust. Too bad Java doesn't do continuations...

However, my point still stands that your underlying problem isn't about converting an OutputStream to an InputStream, but about using an OutputStream filter on an InputStream. Using a pipe is good a way to do it, but for example the propagation of exceptions is only relevant for filtering, not piping.

This is why I think that none of the OutputStream objects and other pipe constructs should really be visible to the user, and that using "filter" in naming is more appropriate than "pipe".

> [io] PipedUtils
> ---------------
>
>                 Key: IO-71
>                 URL: https://issues.apache.org/jira/browse/IO-71
>             Project: Commons IO
>          Issue Type: Improvement
>          Components: Utilities
>         Environment: Operating System: All
> Platform: All
>            Reporter: David Smiley
>            Priority: Minor
>             Fix For: 2.x
>
>         Attachments: PipedUtils.zip, ReverseFilterOutputStream.patch
>
>
> I developed some nifty code that takes an OutputStream and sort  of  reverses it as if it were an 
> InputStream.  Error passing and  handling  close is dealt with.  It needs another thread to do the  work 
> which  runs in parallel.  It uses Piped streams.  I created  this because I  had to conform 
> GZIPOutputStream to my framework  which demanded an  InputStream.
> See URL to source.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.