I forgot to mention a couple of things. At 11:08 AM 1/20/2002, Dirk Verbeeck wrote: >I would implement GetMethod.setUseBuffer to disable buffering and delay >reading the response content. getData() can then directly return the >input stream from the response. A second call to getData should call >reset() on the InputStream and this will probably throw an exception so >you can only get the data once. >Postmethod can use the same method, setUseBuffer will then make that >sendData(InputStream is) doesn't buffer the inputstream. A second >execute needs a reset() in streamQuery throwing an IOException if not >possible.
Earlier today I gave the code a closer look and came up with a similar scheme. However, there seems to be a major problem with it. The problem is with handling the connection. Currently, executeMethod() makes a call to needToCloseConnection() and closeConnection() at the end of the execution. If parseResponse() were to be delayed in the manner we talked of, then it would be up to the method to close the connection if necessary. But it doesn't look like it currently has the necessary information to both make that decision and to execute it. I couldn't think of an elegant and simple way of fixing this. Any proper solution, it seems, would require a substantial overhaul of the existing architecture. And that's the part I don't currently have the time for :) Cheers Dmitry -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
