rename Entity trait?

[scottlamb]

I saw that in 73a3fad, the hyper 0.12.x branch introduces an Entity trait to represent a streaming body. Would it be possible to change the name?

The reason I ask is: as I understand it, the HTTP RFCs use that term in a different way, and I think it'll be confusing. I care because I find the RFC meaning useful; in fact it's a central abstraction in a crate I'm working on that takes care of handling conditional GETs, byte range serving, and such. I could find a different name for my trait but I think it'll be extra confusing to flip between the HTTP RFCs, my crate's thing, and hyper's docs.

To be precise, as I read the HTTP RFCs, an entity is something that has a tag (etag), some headers (entity-headers), and a body (entity-headers). (Maybe also trailers? Unsure.) This trait is just representing a request/response body (and trailers, with HTTP/2); that's only part of the entity's body with range requests / 206 Partial Content.

I confess I don't have another suggestion for the name of this trait, though. You basically want the trait and the concrete type (currently Body) to have similar but not identical names, right? and not Stream, as that's taken by the futures concept? Naming is hard, let's go shopping...

[seanmonstar]

Yea, naming is super hard! 😢 I chose Entity as I noticed its usage in Akka HTTP... 🤷‍♂️

There is a trait, and a "default" implementation, by which this default is used as both a "recvbody", and is a fair option for users as a "sendbody". Here's a few options I've scrapped together:

Trait	Default Impl
Entity	Body
Payload	Body
Stream	Body
Body	DefaultBody

Stream conflicts with futures::Stream, and so would be confusing...

Maybe a trait name of Payload is best?

---

It occurs to me that maybe in the future, a custom base trait wouldn't be needed, and it really could be just a futures::Stream, with traits like PollTrailers existing, and if implemented, they'd be polled, thanks to specialization? I can't say it would all work just as well, as I haven't explored it since specialization isn't stable.

[jolhoeft]

I've tended to think of it as the body stream, being a futures::Stream containing the body of the request or response. Would BodyStream work as a trait name?

[scottlamb]

I like Payload! Thanks!

[seanmonstar]

Additional trait name options:

• Content (like Content-Length describes the Content)
• Transfer

[scottlamb]

I think any of Payload, Content, or Transfer would work well. I searched through RFC 7233 and didn't see any usage of any of those terms that's inconsistent with what this trait does. Mild preference for Payload still; no particular reason.