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. Will the HttpMethodExecutor handle 100-continue responses or not? 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. There is one more idea I'm having on this component, but I'll send that in a separate mail. --- http-cookie --- Should we have an interface CookieStore here? It would be extended by HttpState in http-client. --- http-auth --- Should the interface CredentialProvider be defined here rather than in http-client? Similar to http-cookie/CookieStore. --- 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 ;-) --- http-(reverse)-proxy --- Reverse proxying becomes really useful only if the links within the documents, especially HTML, are rewritten to point to the reverse proxy. This is way messier than spidering, and something we really don't want to get into. Of course there's plenty of stuff to be done apart from content handling, and we could try to implement that while leaving the content handling as an exercise to the reader. But then we should give a less promising name to the component. http-delegate? I have some experience with the topic, but I would have to hold back from this project to avoid polluting it with my employer's intellectual property. --- http-server --- Being a project under the big roof of the Apache family, do we really want to start working on an "HTTP Server"? 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. Of course it never hurts to keep the option open and to factor out the stuff that might be useful on both sides. cheers, Roland
