hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <ROLWE...@de.ibm.com>
Subject Re: HttpClient API redesign: high level component architecture (draft 1)
Date Tue, 11 Jan 2005 07:56:17 GMT
Hi Oleg,

> 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.

See my other mail.

> 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.

So the result of a "spider request" would be an event with the document,
and it is up to the application level event handler to generate followup
spider requests. That does make a lot of sense.

> > --- 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?

That's fine. http-test-server would be fine as well. Just so that
it is clear we do not intend to provide the Java reference for a
server side HTTP protocol stack.

> > [...] Tomcat comes into my mind, and
> > there might be other projects as well.
> > [...]
> 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.

I wouldn't have expected you to do that ;-) When mentioning
Tomcat, I was only thinking of their HTTP connector, Coyote.

I would expect a rather big, if not total, overlap here.
A Tomcat connector would probably be a good use case for
an embeddable server component.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message