Depend on the bytes crate about http

[alexcrichton]

Seems ok to me, but I think we'll learn a lot from experience as tokio-io pushes this change throughout the community. I suspect we've still got tweaks and such to do here.

My main worry is that this would be quite a prominent dependency and would also need to be "1.0 quality", but we've committed to doing that with the Tokio stack so it will happen in time anyway.

[alexcrichton]

That being said I think we should avoid this wherever possible. In the sense that if we can think of an ergonomic way to avoid exposing buffers that'd be great (just more flexible in general). If we must expose buffers then this seems like a good choice.

[carllerche]

@alexcrichton So, the issue refers more to using bytes for storing internal data and not so much for the public API. I would agree that the public API should avoid exposing types from bytes as much as possible and limit when only necessary to avoid copies in some specialty fns.

[alexcrichton]

Oh ok, if this is a private dependency I don't have much of an opinion here.

[carllerche]

Here are the options:

• Don't use bytes and use generics for all types that require byte storage, this will make the API painful
• Don't use bytes and use Vec for internal byte storage, this will require significant allocations / copies and will have a large perf hit.
• Use bytes and try to encapsulate it as much as possible.

[carllerche]

I'll punt to #10 as it has a dependency on bytes.