No complaints here. If you see avenues for improvement, I'm sure we're all for that! I'm not sure if we can drum up Matthew Albright who originally wrote the code. It would be cool to bounce stuff off of him because, as author, he may be able state the pros/cons of his decisions.
If not, we'll just have to get into the details ourselves. Martin Cooper wrote: >Just a few notes on the new multipart code: > >* I was a little surprised to see a hard-coded multipart boundary in there. >The boundary is usually generated anew for each request, using random >values. I'm not completely sure what kinds of problems this might cause. The >only one I can think of is that if you *ever* have the boundary in the >content, it will *always* fail. If the boundary is randomly generated, then >if one attempt to post fails because the content contains the boundary, a >second attempt will most likely succeed, because the boundary will be >different. > > Sounds like a good idea. >* I noticed that the content type for a file part is hardcoded as >"application/octet-stream", with no way that I can see to override it. The >problem is that it is hardcoded in FilePart, but (a) there isn't a way to >add a Part explicitly, and (b) there's no way to tell MultipartPostMethod to >use an alternative FilePart implementation >* There is no way to set additional characteristics of parts, such as the >character encoding. This is a similar issue to the one above related to file >parts, but applies to file and string parts. > >* The only way to create a file part is from a java.io.File instance. There >is no way to use buffered data, or a stream, other than writing it to a File >first. > > It would be nice to have these options as well. I found it easier to deal with building the request off of files because otherwise the memory requirements can get out of hand when dealing with larger files. Is it valid to assume that one can always create a temp file in JVM and use that to store the contents prior to the request? Or is it more benificial to allow one to instantiate off of other sources (Streams or buffers)? In such cases, would the content either stay in memory or get stored temporarily in a file somewhere behind the scenes (another possible option)? It sounds like all could use review and improvement. If there are properties that would be good to make available via get/set methods. This should be releatively easy. I'm not sure if this will get us into deep water in having to deal with various "codecs" and encoding issues that can result. Anyways, it sounds like some of these steps should be well planned before embarking upon them. >* There is no way to create multipart/mixed content. > >Don't get me wrong - I'm glad to see multipart content in HttpClient! I just >wanted to share some review comments, perhaps to be addressed later. > >-- >Martin Cooper > > > > >>-----Original Message----- >>From: Jeff Dever [mailto:[EMAIL PROTECTED]] >>Sent: Tuesday, October 01, 2002 12:26 PM >>To: Jakarta Commons Users List >>Subject: Re: [httpclient] >> >> >>Ok, >> >>I added Matthew's MultiPartPost to commons-httpclient. I >>adjusted the formatting >>and made a few other minor changes, but it looks very good. >>There are still a few >>things that need to be done, which have been noted on the bug report: >>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13165 >> >>Just a note about the stability of HttpClient. We have seen >>MANY changes since >>the 2.0 Alpha release last year. The MultiPartPost files >>that Matthew submitted >>in January applied with ZERO conflicts. This test shows >>that the method >>interface has been VERY stable. >> >>Way to go HttpClient! and thanks to Matthew for the code (and >>Mark for bringing it >>up again). >> >> >>"Mark R. Diggory" wrote: >> >> >> >>>Please look at these old messages: >>> >>> >>> >>> >http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg01701.html > > >>http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg01702.html >>http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg01704.html >> >>Matthew Albright pretty much supplied everything to make this easily >>included into the package back in January of this year. There was no >>response to his messages. >> >>-Mark >> >>Jeff Dever wrote: >> >> >> >>>>I have a >>>>MultipartPost method written for the Commons HttpClient that works with >>>>files stored on the file system such that thier references can be handed >>>>in and the method "streams" everything, much more effective. I've often >>>>wondered why the MultipartPostMethod hasn't been added to the commons >>>>httpclient. But that is also the beauty of the commons library as well, >>>>you can write your own methods if need be. >>>> >>>> >>>> > > >-- >To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
