Fix some bugs, such as decoding of input that contains lots
of padding or whitespace. See
https://code.google.com/p/android/issues/detail?id=66078
Improve performance by correctly guessing the output array
size whenever the input doesn't contain whitespace.
Build Base64 into ByteString, and expose it through there
only.
Use more reasonable names in the implementation.
Previously we had this ugly, awkward release() method that
attempted to manage connection pooling, discarding streams
for caching, and closing broken streams.
Move connection reuse to HttpConnection, with policy informed
by HttpEngine. It specifies what to do when the connection
becomes idle: pool, close or hold. The connection does what
it's told.
This checks that calls into HttpConnection occur in the correct
sequence.
Once this is merged I can follow up by making HttpConnection
responsible for its own pooling rather than relying on HttpEngine
to do that work.
The new (awkwardly-named) HttpConnection class now owns the
socket, and stays around between HTTP requests. It matches
SpdyConnection in lifecycle: it is tied to the socket.
The HTTP transport class is a dumb adapter that adapts the
protocol-specific decisions (chunked-encoding, content-length
stuff).
This should make it possible to make significant simplifications
to how connection recycling works: in a follow up change the
HttpConnection class will know when it can be recycled and take
that action automatically.
The Source API is nice for source implementors: no annoying
skip method, no annoying available() method, just one API to
supply bytes to the caller.
But it isn't as nice of an API for source callers. It lacks
convenient APIs!
This bridges the gap. Calling code should use BufferedSource,
and implementing code should implement Source.
This isn't quite as simple as I had hoped. We still lack something
like DataInputStream/BufferedInputStream that combines a buffer with
a Source. That means there's a bunch of methods that must manually
refill the buffer before acting upon it.
I'm going to continue to migrate code, and will follow up with
changes to simplify this interaction.
GzipSource exceptions used six hex digits instead of
8 to print ints.
readUtf8 always did an extra copy of the bytes being
read.
Moving bytes between buffers crashed when the destination
was empty and the source was a prefix.
InputStream reading returned values in -128..127 instead
of in 0..255.
Should we later support random access for other primitives
or random bulk access, I'd like the prefix to stay constant
(getByte, getInt, getLong, getBytes) vs. the suffix (byteAt,
intAt, longAt). Prefixing may work better for autocomplete
in IDEs, particularly since we already use a prefix for our
consuming reads (readByte, readInt, readLong).
