commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d...@multitask.com.au
Subject Re: [httpclient] 2.0 release plan - Submit Tasks to Bugzilla
Date Mon, 15 Jul 2002 03:16:30 GMT
Cool.

Anything else that pops up, I'll enter there as well....
--
dIon Gillard, Multitask Consulting
Work:      http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers


jsdever wrote on 07/15/2002 12:05:44 PM:

> Ok,
> 
> I'm submitting all the feature requests I have received into 
> bugzilla now.  I'll send out another message when I'm done (might 
> take a couple days!).  Then we can start discussing them and 
> determining which features to include for 2.0
> 
> 
> Jeff Dever wrote:
> 
> > Great.  I folded those into the attached Tasks.txt.  Any other
> > requirements anyone?
> >
> > dion@multitask.com.au wrote:
> > >
> > > Jeff - other requirements:
> > >
> > > - ease of building. HttpClient should be buildable without the user
> > > needing to go away and download extra jars. Maven does a good job of 
this.
> > > - examples showing how to configure logging and why you may want to
> > > - add various timings into the request/response cycle so that timing 
info
> > > can be extracted
> > > - better project samples showing how to use HttpClient in a variety 
of
> > > ways
> > > - better project docs, including checkstyle and clover reports, and
> > > changelog
> > > - automated site and build on a nightly basis to pick up changes
> > > - Links on HttpClient to 'sister' projects such as Slide, Cactusand 
Latka
> > > to show where how it's being used.
> > > - quotes from user's on why they used it.
> > > - better docs for/from us on how to do a release :-)
> > > - Announcements to various mailing lists....
> >
> > 
------------------------------------------------------------------------
> >
> > Non-standards support
> > A simple strict or setLenient is likely inadequate.  Each 
> particular non-standard behaviour should be tagged, and settable 
> from the client.  A mask for particular behavioural features could 
> be provided, with STRICT meaning none and LENIENT meaning all.
> >
> > Plug-in authentication modules
> > Currently only basic authentication is supported.  A 
> Authentication interface should be provided to allow for plug-in 
> support for other authenticaiton schemes, some of which may be 
> application specific and therefore have no place in httpclient.
> >
> > Default headers
> > Provide the ability to set default headers to be sent on every 
> request.  Should be used whenever an object is created or recycled. 
> Needs to be user configurable.
> >
> > Preemptive strike Authentication behaviour
> > Currenntly a 401 is required for httpclient to send authorization 
> credentials.  Real web browsers pre-emptively set the authentication
> header based on some cached host/port/realm/path information and 
> some heruistic.  A configurable item to turn this behavour on should
> be provided.  Check the authentication spec.
> >
> > User interaction authentication
> > Some actions require user input.  Like forwarding to another host 
> or retrieveing authentication credentials.  Should have some way for
> clients to setup listeners for such events so that they can be 
> handled on the fly.  No gui, programatic only.
> >
> > Allow setRequestBody from InputStream
> > Provide a PostMethod.setRequestBody(InputStream) to populate the 
> body.  Allows for highly generic construction of the request body. 
> Particularly useful for proxy.
> >
> > User configurable cookie policy
> > Some user configurable how cookies are handled.  Emulate cookie 
> options in web browsers.
> >
> > Redefine the public API
> > In particular the HttpClient/HttpMultiClient issue must be 
> resolved.  HttpultiClient functionality should be prefered, but 
> HttpClient is the most suitable name.  Consider impact to other 
> projects.  Is java1.1 compatability really an issue anymore?
> >
> > NameValuePair
> > Consider what to do with null arguments.  Consider using a list as
> the value.  Consider making them immutable.  Perhaps name cannot be 
> null but value can be.
> >
> > Returning Null
> > Consider returning empty arrays instead of null.  eg: 
> getResponseBody().  There may be good reason for both null and empty
> array depending on the circumstannces.
> >
> > Null Arguments
> > Consider throwing a NullPointerException or 
> InvalidArgumentException for null argument when they are not 
> allowed.  Be consistant and document behaviour.
> >
> > 2.0 release
> > Many complaints about how old alpha1 is, looking for beta and release.
> > - Announcements to various mailing lists....
> > - better docs for/from us on how to do a release :-)
> >
> > Digest Authentication
> > Implement digest authentication according to the RFC standard. 
> Slide has this already.
> >
> > Slide
> > Why are they still using the old codebase?  It would be nice to 
> pool our efforts and share (which seems to be the whole purpose of 
> the commons).  Should get their benneficial changes and be sensitive
> to API changes for them, Latka and Cactus as well.
> >
> > Move to commons-logging
> > Commons-logging was derived from httpclient.log, still using the 
> old logging which should be dumped.  Some complaints on mailing list
> about setting up commons-logging: should be simple and well documented.
> >
> > Logging policy
> > When to use info vs debug vs warning?  When to log exceptions? 
> Always log debug when swallowing an exception.
> >
> > UnderscoreIsDash http workaround
> > Allow "_" anywhere "-" is required by the spec.
> >
> > Binary file download
> > PostMethod (or any method with a response body) should return a 
> BufferedInputStream for reading the response body.
> >
> > Client side certificate support
> > Add support for this with HTTPS.  Apparently not too hard.
> >
> > Need to agree on a tracking system
> > Currently the mailing list, a file on the web and a file in cvs 
> all have content change/problem report information in them.  Need a 
> way to see which features are required, which are needed for 2.0 and
> which are later.  Use bugzilla as it has support for all this.
> >
> > Handle virtual hosts, relative urls, multi-homing
> > Need to be able to open a socket to one ipaddress (or hostname) 
> and then include a virtual hostname in the Host header. Use InetAddress 
class.
> >
> > User-Agent
> > User configurable item to set the user agent without haveing to 
> set it on a per method basis.
> >
> > Developer documentation
> > Provide more example code in CVS and give a clear link on the 
> website.  A walkthrough of the API.  Documenntation suitable for new 
users.
> >
> > Response handlers
> > Perhaps plugin handlers should be used to handle various ranges of
> http responses.  Could be used to respond, auto-forward, resubmit 
> ... Could solve the difficulty in handling a 303 response.
> >
> > Proxy authentication
> > Fullly supported proxy authentication and handling.  Currently 
> hidden behind the HttpMultiClient?  Needs functional/unit testing.
> >
> > HttpMultiClient connection properties
> > Properties such as proxy info, timeout, ... instead of in the 
> HttpConnectionManager.
> >
> > RFC 2965 Support (Port sensitive cookies)
> > RFC 2109 doesn't consider port numbers when matching and filtering
> cookies. RFC 2965 does. Modify the Cookie class so that it 
> (optionally?) supports RFC 2965, while maintaining support for RFC 
> 2109-style (portless) cookies.
> >
> > Build
> > - ease of building. HttpClient should be buildable without the 
> user needing to go away and download extra jars. Maven does a good 
> job of this.
> > - automated site and build on a nightly basis to pick up changes
> >
> > Instrumentation for Timings
> > - add various timings into the request/response cycle so that 
> timing info can be extracted.  Could perhaps pump this data out to 
> XML for post processing by user code.
> >
> > User/Developer Documentation
> > - quotes from user's on why they used it.
> > - better project docs, including checkstyle and clover reports, 
> and changelog
> > - examples showing how to configure logging and why you may want to
> > - Links on HttpClient to 'sister' projects such as Slide, Cactus 
> and Latka to show where how it's being used.
> >
> > Example Code
> > - better project samples showing how to use HttpClient in a 
> variety of ways.  There is already a src/examples directory which is
> excellent.  Its in the right place and should be build with a full 
> compile, if only to know how any API changes may effect example 
> code, and that we will be required to keep them current.
> >
> > 
------------------------------------------------------------------------
> > --
> > To unsubscribe, e-mail: 
<mailto:commons-dev-unsubscribe@jakarta.apache.org
> >
> > For additional commands, e-mail: 
<mailto:commons-dev-help@jakarta.apache.org
> >
> 
> 
> --
> To unsubscribe, e-mail: 
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
<mailto:commons-dev-help@jakarta.apache.org>
> 

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message