Remove "HB" prefix #395
Remove "HB" prefix #395
Conversation
|
I'd prefer "HTTPResponder" over "RequestResponder" |
I'm happy to go with that. Was just looking for something a little less generic that Responder |
@Joannis and done! |
There was a problem hiding this comment.
Looks like an improvement overall although has the downside of a bit being less clear.
I'd put some @available(*, unavailable/deprecated, renamed: "NewName") typealias OldName = NewNames to make it easier to migrate to these new names for the beta testers. Should be easy for us to do but will mitigate a ton of hassle considering Xcode freaks out after encountering a number of errors (i've noticed VSCode does properly show all the numerous errors in these situations, that's why i'm blaming Xcode specifically.)
|
I agree with @MahdiBM 's remark here. We'd remove that in the next beta or on release, but I think it's a good idea for sure. |
I've implemented this and it works quite well, cheers |
|
Quick question / suggestion: how about renaming application to server? 🤔 |
We are already using Server for the actual server. Application is the server plus glue code that connects it to the router, any additional services attached and the date cache. I'm not enamoured with the name Application either, but can't think of an alternative I'm happy with. |
Is that underlying server the HTTPServer? Maybe we could differentiate that layer by using the HTTP prefix there and simply use Server for HBApp? 🤔 |
|
Server is a generic type with a generic parameter ChildChannel that defines the protocol the server supports. It be could HTTP1.1 but doesn't have to be. So calling it HTTPServer doesn't make sense. |
|
I see, how about (Generic)NIOServer or something related to network? 🤔 |
Sorry Tibor we've decided to stick with Application. It reflect prior art and the symbol Server is already used in a more applicable situation |
Also renamed some symbols to avoid clashes