Roland Weber wrote:
Hi Oleg,
Hi Roland,
Please do not get me wrong. This is not to discourage you from
questioning the sanity of the existing design or to prevent you from
evaluating alternatives or writing patches. I very much appreciate the
fact that you take time to review the HttpCore API and identify weak
points in the present code. Just this very particular issue does not
seem to deserve all the cycles we have invested into it
'Chunk-encoding' and 'identity' are the only transfer codings in use
nowadays and this is unlikely to change in our life time. I have never
seen transfer compression used anywhere, because content compression is
enough.
Hm. I was implicitly assuming that all this compression stuff one reads
about when searching for "web acceleration" is primarily transfer-encoding.
But this mail, and the discussion leading up to it, suggests you are right
and I am wrong:
http://hypermail.linklord.com/new-httpd/2003/Nov/2406.html
Another point, the chunk encoding MUST be the last one applied, it
If we introduce an interface for pluggable transport encodings, it
shouldn't be restricted to just chunked plus one other. (Although
that would probably cover every reasonable use case I could come up
with.)
I did not mean to imply that. All I am saying is the chunked coding plus
others (plural) is a MUST requirement of the HTTP spec. So, the transfer
encoding order cannot just _any_ arbitrary combination of codecs. At the
very least it also takes a provision that the chunk coding is the last
allied and it is applied once only. This all gets way too complex for a
very limited practical gain.
On the sending side, putting request interceptors into the
right order will be sufficient. On the receiving side, the order of
the transport encodings is determined by the server via the header.
We know "chunked" is the last, any others can come in arbitrary
order. An interface for shuffling the response interceptors would
be far worse than my suggestion. But after reading above-linked
discussion, I no longer think we need pluggable transport encodings.
Everything else I mentioned as potential applications for stream
layering were add-ons: things you could do with the mechanism if
it's there, not things for which the mechanism is actually needed.
I am not sure I understand entirely the problem you are having with
http-async. You want to preprocess an entity before the connection is
allocated? What for?
Remember my mail about preprocessing being done by the application
thread, while the sending is done by the background thread? The
preprocessing is done before the request ever gets queued. That's
in the good old tradition of detecting problems as early as possible:
requests that fail in preprocessing are not worthy to be queued.
The connection will be allocated at the other side of the queue.
Have a look at SimpleHttpDispatcher.sendRequest if you find the time.
I will. However, I am still not entirely sold on the whole concept, but
I am prepared to wait and see how things shape up.
The only *real* problem that I see at the moment is that
HttpEntityGenerator and HttpEntityWriter interfaces are not symmetric
from the design purism standpoint.
I agree now. You mentioned an idea to refactor at the expense of
exposing the streams at the connection. If that refactoring requires
the connection to be available for preprocessing, I'd rather keep what
we have right now.
We do not necessarily have to keep what is there. However, I do think
that the transfer encoding code should not be treated the same way as
the content encoding and that the transfer encoding code does not really
belong to the request / response interceptor layer.
I had one other problem: I didn't know how to detect whether the
entity in the response is a "streaming" entity depending on the
underlying stream of the connection, or whether it is an entity
that has been read into memory completely. In the second case, the
connection can be re-used immediately, in the first case it can
only be re-used after the entity has been consumed or some kind
of abort has been triggered.
I've seen that the EntityGenerator interface returns a BasicHttpEntity,
so the entities generated by the DefaultHttpClientConnection are never
in memory. Still, the HttpClientConnection interface can be implemented
differently. But this can be addressed in the JavaDocs.
I see. Do feel free to suggest a fix for this problem.
More strongly I think we should put our efforts elsewhere at this point
of time: HttpAsync, HttpNIO, HttpCookie and HttpAuth.
Fair deal. I might add HttpConn, since more sophisticated dispatchers
will require a connection pool.
Mike,
If you are following this discussion, could you please let us know if
you managed to get some work done on HttpConn?
We can redesign
HttpEntityGenerator and HttpEntityWriter at any moment before the API
freeze (which is nowhere in sight)
That comes as a surprise to me. I thought the release of the http-core
alpha1 you are planning for March implies some kind of API freeze.
(Note to self: learn more about the HttpComponents release process :-)
Hell no. The API freeze (at least to me) is when the first BETA is
released and API changes are no longer permissible. I do want to release
the first ALPHA asap, because I see it as the only way to get more
people looking at the code. This by no means implies no changes to the
API in the future. We might have to have a half a dozens of ALPHAs (or
as many as it takes) before we are reasonably comfortable with the API.
I certainly do not see that moment coming any time soon (not this year even)
Oleg
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
