commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amir D. Kolsky" <a...@kolsky.com>
Subject RE: HttpClient development
Date Tue, 07 May 2002 08:08:44 GMT
http://mpt.phrasewise.com/2002/04/13

Just to put things in perspective -- the above is a link to a piece about "Why Free Software
usability tends to suck" (make sure to read the sequel too). Keep in mind that the "user interface"
for something like HttpClient is NOT a screenfull of pixels and keyclicks but the interface
definitions and documentations....

Thanks, Amir

-----Original Message-----
From: Amir D. Kolsky 
Sent: Tue, May 07, 2002 12:50 AM
To: Jakarta Commons Developers List
Subject: RE: HttpClient development


I know how it works, and I am willing to put in effort to rectify what's wrong. But my gut
feeling, and I've been doing software architecture for years, is that the way the package
is done is too complex.

For example, how is someone to start a session?
HttpClient?
HttpMultiClient?
URLxxxMethod?
HttpConnection?

Patching the package to work around problems runs its course eventually -- I think that eventuality
has arrived...

I propose to take a step back, look again at what Http is, what is required of a client, and
provide a progressive set of functionality all stemming from a single "class" in increasing
functionality.

This means that for simple tasks, you do what you basically do today --
Create HttpClient, create a xxxMethod, presto.

You want to do more complext things -- you still build off HttpClient 
--> Mutliple Clients -- not as a seperate class but as a natural extension to HttpClient...
(I.e. HttpClient goes, Multi stays as the base for everything)
--> Get the connection from the HttpClient and do stuff to it
...

This will make the interface simple for beginners in a few lines of code.
ADD some more lines of code and you can do fancier stuff...

Another example -- if you can only do body OR parameters for a Post method, don't write code
that allows you to do both, and throw an exception... Write code that forces you to decide
-- easier for everyone.

If we know -- from the RFCs -- that some HTTP headers exist, and follow certain rules (e.g.,
language, q-values, booleans) -- allow people to treat these headers as methods -- provide
get and set methods for them. As RFCs are added and integrated into HttpClient, add more methods.
In the interim, provide a general purpose header setting method.

This might seem very verbose, but in the end you will end up with a very easy to use, extend
and understand package -- which is what we want to achieve.

So my proposal is to start afresh with a LAYERED approach to function. Lets see what the simplest
and commonest requirements are and put them in level 0, next batch in level 1, etc...

In the meanwhile, the existing code will be maintained, and will in fact serve as the base
for the code of the next release. 

Marc, do you think you'd like to run this show?

Amir

-----Original Message-----
From: Marc.Saegesser@apropos.com [mailto:Marc.Saegesser@apropos.com]
Sent: Mon, May 06, 2002 11:02 PM
To: commons-dev@jakarta.apache.org
Subject: RE: HttpClient development


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:amir@kolsky.com]
> 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: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>


--
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
View raw message