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
Date Sat, 13 Jul 2002 09:43:00 GMT
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, Cactus and 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....

That's all for now.
--
dIon Gillard, Multitask Consulting
Work:      http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers


jsdever wrote on 07/12/2002 07:07:24 PM:

> I went back to October and read every single email posted with
> [httpclient] in the subject line (and a few that didn't).  I tried to
> capture all the requirements proposed over the last 8 months. (oh my
> god).  From this I extracted a list of features that have been proposed,
> and possibly discussed perhaps even with patches but have not been
> completed (below).  I've also proposed a development cycle so that we
> can all decide what the 2.0 content will be.  Then we can work towards
> it and get a release out the door before the end of summer.
> 
> 
> HttpClient 2.0 Proposed Development Cycle
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> ** Now-Sunday: Call for requirements  **
> Add any other requirements to this list that may have been missed 
> 
> ** Sunday: Add to bugzilla **
> Then on Sunday to put them all in bugzilla.  (I'll volunteer to do that)
> 
> ** Monday-Friday: Update bugs and Vote **
> Everyone will be welcome to add their thoughts directly into the bug. 
> Bugzilla is easy to use so jump right in and and some comments to
> solidify the ideas.  Everyone should use the voting feature in bugzilla
> to pick the bugs they most want to see complete for the 2.0 release.
> 
> ** Saturday-Sunday: Prioritize bugs **
> The release manager will have to make a call on which features are in
> and which are out based on the votes.  He'll then have to modify the
> priority and severity, and mark them either for the 2.0 release or the
> next release.
> 
> ** Following  weeks:  Select bugs and fix **
> Then everyone can pick the bugs marked for the 2.0 release, and start
> fixing them.  patches should be added as an attachment to the bug and
> mailed to the list for inspection. 
> 
> 
> HttpClient Proposed Feature List
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 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.
> 
> 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.
> 
> 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. 
> 
> 
> 
> 
> "Waldhoff, Rodney" wrote:
> > 
> > Jeff Dever wrote:
> > 
> > > The current release is 2.0Alpha1 from October 8th.
> > > The RELEASE_PLAN_2_0.txt only outlines until last
> > > September.
> > 
> > The assumptions behind the 2.0 release plan didn't pan out.  The idea 
behind
> > that plan was to take the 2.0A1 feature set and code base (the 
refactoring I
> > did on Slide's initial import as described at
> > 
http://www.mail-archive.com/jakarta-commons@jakarta.apache.org/msg03954.html
> > ), fix the outstanding issues and release it.  Instead, the community 
moved
> > toward adding new features and functionality, many of which were 
sorely
> > needed (multiclient, stronger proxy/ssl support, etc.).
> > 
> > > It would be nice to have some milestones
> > > in place to organize towards a release for
> > > this summer.
> > 
> > Agreed.
> > 
> > > But it seems that what we really need is
> > > plan to release to 2.0, alpha, beta, ship.
> > 
> > Agreed, but following the milestone plan.
> > 
> > I think, and based on some of the threads here on commons-dev, others 
do
> > too, that we need to make some design decisions and probably design 
changes
> > in the httpclient code base.  A user-specified policy strategy for 
dealing
> > with things like security, cookies, authentication, 
connection-handling,
> > spec-tolerance, etc. seems like it would address a number of the user 
issues
> > and complaints we encounter.  The relation between (and justification 
for
> > having both) HttpClient and HttpMultiClient isn't clear to me.  There 
have
> > been a number of ideas kicked around on refactoring the HttpMethodBase 
tree,
> > etc.  I think we need to work out what we want httpclient to do and to 
look
> > like (even if just in the very immediate term), and I agree that the
> > milestone plan is probably the best way to manage (and communicate) 
that
> > evolution.
> > 
> > > Rodney, are you able to come back
> > > as release manager?
> > 
> > I'd be glad to help where I can, but I don't have the bandwidth right 
now to
> > keep up with all of the changes that have made and proposed over the 
last
> > few months.  If anyone else wants to volunteer (dion?, marc?) by all 
means,
> > have at it.
> 
> --
> 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