Changed HTTPConnection to include option for using a call back method to set httpResponse #103
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Changed HTTPConnection Changed method httpResponseForMethod:URI: Added method httpResponseForMethodFinished:URI: This change forces the server to wait to send the response until the app server would like the response sent. This allows for multithreaded work to be done from the app server before letting client know results. Example: A PC (client) ask the iOS device(app server) on same wifi network to start up a process and needs to know if the process was successful or not. The process on the app server requires the app server to make a call to another server(data server) to get data. When the app server makes a connection to the data server it creates another thread. The original design would send the response before the app server's connection to the data server was finished doing it's work. The new design allows the app server to send a response based on what on interaction with the data server.
Changed HTTPConnection Added property useCallBack, default value of false Added method useCallBack Added method setUseCallBack: Changed method httpResponseForMethod:URI: Added method httpResponseForMethodStart:URI: Added method httpResponseForMethodFinished:URI: This change if useCallBack is set to true allows the server to wait to send the response until the app server would like the response sent. This allows for multithreaded work to be done from the app server before letting client know results. Example: A PC (client) ask the iOS device(app server) on same wifi network to start up a process and needs to know if the process was successful or not. The process on the app server requires the app server to make a call to another server(data server) to get data. When the app server makes a connection to the data server it creates another thread. The original design would send the response before the app server's connection to the data server was finished doing it's work. The new design allows the app server to send a response based on what on interaction with the data server.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changed HTTPConnection
Added property useCallBack, default value of false
Added method useCallBack
Added method setUseCallBack:
Changed method httpResponseForMethod:URI:
Added method httpResponseForMethodStart:URI:
Added method httpResponseForMethodFinished:URI:
This change if useCallBack is set to true allows the server to wait to send the response until the app server would like the response sent. This allows for multithreaded work to be done from the app server before letting the client know the results.
Example:
A PC (client) ask the iOS device(app server) on same wifi network to start up a process and needs to know if the process was successful or not. The process on the app server requires the app server to make a call to another server(data server) to get data. When the app server makes a connection to the data server it creates another thread.
The original design would send the response before the app server's connection to the data server was finished doing it's work. The new design allows the app server to send a response based on what on interaction with the data server.