Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sync origin #12

Merged
merged 20 commits into from
Feb 13, 2014
Merged

sync origin #12

merged 20 commits into from
Feb 13, 2014

Conversation

carck
Copy link
Owner

@carck carck commented Feb 13, 2014

No description provided.

squarejesse and others added 20 commits February 7, 2014 20:15
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).
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.
Initial implementation of an OkHttp-backed curl clone.
Add -X to okcurl, permitting HEAD requests
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.
…urce

Use OkBuffer in spdy/3 source stream.
…urce

Use OkBuffer in http/2 source stream
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.
carck pushed a commit that referenced this pull request Feb 13, 2014
@carck carck merged commit 7e10e36 into carck:master Feb 13, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants