Does the Server request information from the Client?
In a client / server system, is it considered a good architecture for the server to "ask the client" method for more information? If so, what's the best way to design such a scenario? Is there a "template" for this?
For example, suppose an end user selects a set of records they want to delete in the client interface, then the client makes a "delete records" call to the server with the recordset as a parameter. The server then finds a subset of those entries that are "special" in some way and therefore need to be confirmed by the user. Is it appropriate for the server to somehow "call back" the client using the "confirm records" method, while continuing the initial call from the client to the server?
What about more complex server calls that may require lengthy "conversation" between server and client?
source to share
This callback overrides the client and server roles. In many of these types of architectures, the client does not have the ability to listen to requests. If so, you start looking at a P2P system. Perhaps something like this might work.
client code:
special_records = server.deleteRecords(records)
server.deleteSpecialRecords(special_records)
server code:
def deleteRecords(records):
special_records = detectSpecialRecords(records)
reply(special_records)
actuallyDeleteRecords(records - special_records)
So the first call to deleteRecords will return a list of these special records that need to be explicitly deleted. Hope this helps.
source to share
Some answer that says "The records x, y and z were not deleted, please try again with the I_RELLY_WANT_TO
one set to delete them" would seem like a reasonable solution to me.
General template; don’t ask, don’t do, and don’t report, let the client decide what to do next. This can be done in the context of a persistent connection as a form of dialogue.
Not really my field, so ... add 64 mg NaCl
source to share
The client sends a list of files to delete, right? Just let the server respond with a list of success statuses, indicating which file was deleted and which was not, and possibly why it was not deleted (does not exist, no permission, etc.).
If the general case is that all files were deleted successfully, perhaps start the response with a status field indicating if all files were deleted or if the client really needs to evaluate the status codes to see how this operation went.
With this answer, the client should be able to update their view of the state of the server, at least with respect to the files that were selected for deletion (i.e. remove from the UI those files that were deleted successfully, but also those that are larger do not exist, they can also indicate those files that the server could not delete due to missing permission).
source to share
I think this arrangement is totally fine. There is nothing stopping the server from responding with a request to the client for more information and for the client to provide it. As long as the socket connection is open, you have fluency to send messages back and forth.
I saw a diagram where the client sent a message to the server and after that did nothing but a little layer above stdin / out and the filesystem on the local machine as the server was in control of it.It worked fine and was very fast.
source to share