>1) I'm sure stuff like this is unintentional: >- * @author Ortwin Glück >- * @author <a href="mailto:[EMAIL PROTECTED]";>Mike Bowler</a> >+ * @author Ortwin Glück
That was actually a part of a massive Russian conspiracy intended to undermine the existing world order <grin> >2) I thought we had deprecated the "use disk" methods in GetMethod, but >I don't see it that way in the source. Didn't we agree that those >methods were buggy unnecessisary but we can't remove them yet so we >decided to deprecate them? It would have an impact on your >EntityEnclosingMethod. That can be done a bit later once we have design issues ironed out > 4) Magic number to set the buffer size byte[] tmp = new byte[4096]; It'll take it into account >6) can you make any new methods/classes @since 2.0beta1 I'll do so >The client really does not need so much access to the parameters and >this is classic interface bloat. All the client needs is: >setRequestBody(String stringBody) >setRequestBody(InputStream streamBody) >setRequestBody(NameValuePair[] parametersBody) It's brilliant. I really like the idea >Internally we should just have one "body" datamember, which would be an >InputStream. When setting the request body, if the streamBody() form is >used, its trivial. When the stringBody() is used, create a >StringInputStream which is easy. When the parametersBody() form is >used, url encode it to a string, and use that as the input stream, also >easy. I am not sure if we can totally do away with additional byte[] buffer member variable, unless you are prepared to completely sacrifice ability to repeat requests (if case of re-authentication, for instance). It may be a reasonable thing to do, though, as it turns out Post & Put requests MUST NOT be automatically redirected without user intervention according to RFC 2616 Let me know what you think Cheers Olegolas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
