hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: HttpClient API redesign: high level component architecture (draft 1)
Date Mon, 10 Jan 2005 20:08:28 GMT
Hi Roland

See my comments in-lined

On Mon, 2005-01-10 at 16:26 +0100, Roland Weber wrote: 
> Hi Oleg,
> I just got back to work today. What a nice surprise to
> see the first version of the 4.0 high level design :-)
> Here are my thoughts:
> --- http-common ---
> "The parser must only be able to..."
> Do you mean "does only have to be able to",
> or "is not allowed to handle anything else"?
> I guess it's the former, but I want to be sure.

I meant the former indeed. I'll update that section shortly

> Will the HttpMethodExecutor handle 100-continue
> responses or not?

Excellent question. I have not thought about it in great details yet.

>  I'd say no, since they don't
> indicate errors requiring a retry.
> The interface of the HMExecutor will get more
> complicated if a response can be available before
> the request has been fully transmitted, but hiding
> 10x responses will cause problems elsewhere.
> So I would prefer an executor with an interface
> that at least allows for asynchronous execution,
> including intermediate responses.

I personally see little practical benefit in exposing 1xx responses
outside the method executor, as they do not represent an atomic
operation IMO. So I would advocate hiding 1xx but open to discussion.

> --- http-cookie ---
> Should we have an interface CookieStore here?
> It would be extended by HttpState in http-client.

Good idea

> --- http-auth ---
> Should the interface CredentialProvider be
> defined here rather than in http-client?
> Similar to http-cookie/CookieStore.

Good idea

> --- http-spider ---
> Spidering requires content handling, which can
> get ugly really fast. I guess by defining a very
> simple interface to obtain the links from a
> document and by having intentionally simple
> implementations, we could keep that in check.
> But we'll need an inner circle of evil comrades
> to deny requests for more intelligent content
> handling ;-)


I tend to think of http-spider having a very simple event driven design
akin to that of SAX. All we probably want to do here is fire a bunch of
events and let the higher level components deal with the details.

> --- http-(reverse)-proxy & http-server ---
> Being a project under the big roof of the Apache
> family, do we really want to start working on an
> "HTTP Server"?

Of course not. The thing is we do need a simple HTTP server to be able
the client side stuff. We can still keep it buried deep inside our test
cases, but I would rather try to develop it generic enough to be useful
beyond our testing framework.

What is we keep the potentially contentious "server" term out of it and provisionally call
it http-infra?

> In general, the idea makes sense. We do have
> a lot of experience with HTTP. But there are
> others that are already working on the server
> side in Java. Tomcat comes into my mind, and
> there might be other projects as well.
> Rather than just taking what we got and extending
> it to the server side, we should search for projects
> that would make use of this component, then ask
> proactively what they would need and if they have
> code to share with us. That way, we might even
> find people willing to help with development.
> If we don't find projects willing to use our server
> side component (once there is one) beforehand,
> we shouldn't put any effort in it. This will prevent
> us from getting into somebody else's turf.

A certain conflict of interests and overlap in development efforts is
inevitable. However our focus would be completely different. What I was
thinking of is a simple embeddable server component. I by no means
advocate a development of a full-blown servlet container.

> Of course it never hurts to keep the option open
> and to factor out the stuff that might be useful
> on both sides.

Let's keep it as a long-term option. Anyhow, first things should come first.



To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org

View raw message