Skip to content

[URLSession] Refactor common protocol code into a new class #1355

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

Closed
wants to merge 4 commits into from

Conversation

saiHemak
Copy link
Contributor

@saiHemak saiHemak commented Dec 5, 2017

The new class called NativeProtocol now contains a protocol-agnostic implementation which is currently used by HTTPURLProtocol, and in future will be used by other native protocols - FTP, Data etc.

TransferState has 1-on-1 relationship with EasyHandle and is independent of protocol.Hence it has been moved out of the http folder.

HTTPCharacters has been renamed to Delimiters which has characters or delimiters like CRLF which is common across the protocols.
eg: FTP headers and HTTP headers end with CRLF characters.

Common implementation of header parsing has been moved to new file Message.swift and the code specific to HTTP has been retained in HTTPMessage.swift.

@pushkarnk
Copy link
Member

pushkarnk commented Dec 5, 2017

Looks like there's some problem here? Status checks still running.

@alblue
Copy link
Contributor

alblue commented Dec 5, 2017

They were going to take the systems down to install new versions of Xcode - there was a mail out about it. We should try kicking it off again later.

@alblue
Copy link
Contributor

alblue commented Dec 6, 2017

@swift-ci please test

TransferState has 1-on-1 relationship with EasyHandle and is independent of protocol.Hence it has been moved out of the http folder
Common implementation of header parsing has been moved to new file Message.swift and the code specific to HTTP has been retained in HTTPMessage.swift
The new class called NativeProtocol now contains a protocol-agnostic implementation which is currently used by HTTPURLProtocol,
and in future will be used by other native protocols - FTP, Data etc.
@saiHemak
Copy link
Contributor Author

saiHemak commented Dec 6, 2017

Splitting the commits to improve readability of each commit.

@pushkarnk
Copy link
Member

@swift-ci please test

1 similar comment
@pushkarnk
Copy link
Member

@swift-ci please test

@alblue alblue self-requested a review December 7, 2017 11:25
Copy link
Contributor

@alblue alblue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we split this up into separate PRs that can be independently tested and reviewed?

I appreciate that you've split the commits up, but in fact, the commits won't build independently (because you've defined the build file to move the files in one commit, then performed the move in another commit). As such anyone doing bisect-style debugging might land on something that hasn't been tested and isn't going to work.

You've also mixed a couple of things here; there are a couple of moves, and an extracted class. I'd prefer these to be done in separate PRs, because then they can be tested independently of one another (and so that it's easier to review them - GitHub isn't great at showing you single commits for review purposes).

I'd recommend doing the moves first (along with the changes to references in the Xcode project), then we can test and build that - after that's done, we can look at the refactoring.

@ianpartridge
Copy link
Contributor

I agree with Al.

@saiHemak
Copy link
Contributor Author

@alblue Thanks for the review .The code under TransferState.swift and Message.swift are extensions of _NativeProtocol class.So to compile TransferState.swift and Message.swift individually _NativeProtocol class should be in place.Hence I had to raise the PR with movement and refactoring together.
However, to address your comments I am trying to compile with a skeleton of _NativeProtocol class in place and perform the movement under one PR ..

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