Re: [httpclient] [proposal] Remove the "httpclient/methods/Url*Method" classes

[Jeff Dever <js...@sympatico.ca>]

Ok, back to basics here.

What are we trying to provide?  The sun HttpUrlConnection provides basic http
client side services.  We are trying to provide somthing more, a core library
for a http based client application.  We're doing redirects, forwards, proxies,
authentication, cookies and lots of other services that are desirable in a http
client application.

So what does a web client need to do then?  A web browser is the classic
example.  When a GET happens on a web page, a single URL is given and a single
connection is made to a particular webserver.  But in order to complete the
page load, the browser must parse the html and pull back all the embedded
images.  These might be on the same server with relative urls or they might be
on different servers with absolute urls.  Regardless of where the subsequent
GETs are made to, they are done in parallel for performance reasons.

So what does that mean for our HttpClient?  Initially it means that all the
information necessisary for performing a http request is in the URL.   We have
to manage multiple connections to different servers, which may or may not be
secure.  If we are handling the connections, then we will also be responseable
for parallelizing the requests.  There might be a proxy in the way as well, so
we have to handle that as well.

OK, so what does that mean for our HttpClient/MultiClient dilemma?  First of
all, the startSession methods in HttpClient stink.  It should just take a
method, execute it, and open a connection if required or reuse one if it is
already established.  Multiple concurrent calls to executeMethod should be
parallelized.

We should also not be too afraid of making changes to the public interface.
I started going through the classes to see what has been 1.0 and whats new in
2.0, and there is SO much new in the interface, and SO much removed (in the
case of the methods at least) that really we should take this as an opportunity
to provide a decent, clean, simple interface as the most important requirement
for 2.0.

Does that help?



dion@multitask.com.au wrote:

> These methods were added to work with HttpMultiClient. HttpClient is a
> 'session' style object, you start a session with a host, execute URLs and
> end the 'session'.
>
> HttpMultiClient cares not what host URLs go to and is not a session style
> object, as the host is part of the URL.

I'm still in favour of removing the Url*Method classes, and doing the parsing
of the "path" as a full url and doing somthing useful with the scheme, host and
port, if they exist, and handling it as a path if its relative.

>
>
> This has been one of my main issues with the HttpClient/MultiClient
> classes - what sort of interface do we want to keep - the session style or
> non-session style? MultiClient can reasonably easily be retrofitted to
> handle a single 'default' session, but we need to make a decision on the
> API front.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [httpclient] [proposal] Remove the "httpclient/methods/Url*Method" classes

[Sung-Gu <jericho at apache.org>]

----- Original Message -----
From: "Jeff Dever" <js...@sympatico.ca>

> OK, so what does that mean for our HttpClient/MultiClient dilemma?  First
of

What's the benefits by MultiClient class?
I think, there two sides.  It uses:
1.  URL as a contructor or arguments (easy to handle URL, - it's as a String
though)
2.  HttpSharedState (managable clients)

The number 1 gives the API client programmers intuitive uses.
But as a wrapper, it's not much enough to use and integrate in details...

The number 2, it should be follwed as the nice example of http 2.0 features

Let me comment them out here some...  ;)

What's the merit of usingt #1?   Is that really required?
Then... which side for and where?

I thinks that's so required for the client extensiblity.
But not a just string... not a just container containg URI components...
We have aleady known the escaped and character encoding issue
about URI thingy.. Why don't we integrated with it?

BTW, where is the good position for it?  Or where is it useful?
If we can specify the purpose to be useful, that might be there...
I don't think either, in a wrapper side like Url*Method...

The http use the XML documents as one part of the protocol.
So it's required to express the escaped whole URI form,
not only the path part.  So it's needed to produce the own
string information as many as required....
(It may be the protocol or communication part, I will say it)
In the API client programmer side or the application user side,
It's also required to use and manage http client information.
(It may be the document part, I will say it)

Then, here, we can think how to take advantages of  #1 and #2.
What's your next imagination, please try to desribe it...  ;)

> We should also not be too afraid of making changes to the public
interface.

Ok for the better and extensible archicture, I believe.

> dion@multitask.com.au wrote:
>
> I'm still in favour of removing the Url*Method classes, and doing the
parsing
> of the "path" as a full url and doing somthing useful with the scheme,
host and
> port, if they exist, and handling it as a path if its relative.

Reasonable, I think, with the above comments.

Sung-Gu



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>