Please provide specific examples of *what* you found confusing and *why*.
Better yet, supply patches or documentation that you think make things
better, this is a volunteer effort.

There are two usage models that I know of:  HttpClient and HttpMultiClient.
HttpClient is the original model and its design is based on its initial
usage inside Slide.  When the Commons project was created the HttpClient
portion was made public so it could be used by more projects.  It still has
a lot of its original flavor.

HttpMultiClient exists because I saw a need that was not met by the existing
HttpClient.  HttpMultiClient provides an interface that is more like a
normal browser (it uses URLs, it handles multiple requests simulataneously,
its thread safe, etc.).  I won't claim that its complete yet.  I still have
several things I want to do.  One of those things is a user's guide, but
honestly, that's still pretty low on the priority list right now.  There are
still bugs and features that need to be addressed.

I saw a need, I wrote some code.  See how that works?  There were bugs, I
fixed some code.  See how that works?  

I'd love to see an 'Examples' page on the HttpClient web site.  I think a
basic user's guide or introduction document would be great.  I won't get to
those in the next few weeks, though.

Do you see a need?  Do you think something is missing?  Remember how it
works?


Marc Saegesser 

> -----Original Message-----
> From: Amir D. Kolsky [mailto:[EMAIL PROTECTED]]
> Sent: Monday, May 06, 2002 11:52 AM
> To: Jakarta Commons Developers List
> Subject: RE: HttpClient development
> 
> 
> As a developer new to HttpClient I have to admit to be 
> extremely confused by the package. Several usage models are 
> concurrently impelemented, virtually no documentation exists 
> as to how to do what, and worse, it appears that there is no 
> one at the helm to guide this package in a coherent and 
> architectured manner.
> 
> If HttpClient is to succeed, then beyond being bug free (as 
> much as possible), and adhering to the RFCs, it must present 
> a coherent and well documented interface to the programmers 
> who are to use it.
> 
> If you guys are willing to invest some time in designing the 
> HttpClient NG (as some organizations like to call their next 
> release), I would be happy to actively participate in it. 
> There must be, however, someone coordinating this effort -- 
> making sure that design, implementation, documentation and 
> the test suite are all complete and in sync... Otherwise, 
> frankly, I don't see a real chance of this package taking off 
> and being used by anyone beyond those actually developing it, 
> and it will lose big time to HTTPClient.
> 
> Amir
> 
> --
> 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]>

Reply via email to