Bore
May 4th, 2003, 05:54 PM
We are having a debate in one of our engineering groups over whether to use a polling model or a notification model in part of the code. I've been searching newsgroups, compsci journals and this forum for a while but haven't found any general discussion of how to choose between polling or notification. My first question is whether anyone knows of a good discussion of what the issues are.
In case anyone has some of his own input, here are some details. The UI has dropdown menus in it. The dropdown menus may look different depending on the state of the app. The simplest example is in the "Edit" menu. If the state allows the user to use the "Cut" command, then "Cut" should be enabled. Otherwise, "Cut" should be disabled. Simple enough.
It seems that the easiest option, that of having the menu itself analyze app state and take care of itself, is not feasible. Getting at certain elements of the app state is just too slow, and it makes menu dropdown sluggish.
An alternative that everyone seems to like is to have some other part of the code analyze the app state and store the results in a central object, such that a menu dropping down can go look there and take care of itself quickly. The problem then arises as to the model to use for keeping that central object up-to-date.
Some in the group want to have Windows send us a periodic message, ON_IDLE, telling us that nothing else is going on. At this point, a function would run to analyze the app state and update the central object. This is what we're calling the "polling" model, or "pulling".
Others in the group want to have the parts of the code that may affect relevant app state call into the central object at the instant that the state is changed. This is what we're calling the "notification" model, or "pushing".
Those in favor of polling say that Windows is providing this service for us, so why not use it? Also that it centralizes the code that has to perform the state analysis.
Critics of polling say that it is a model to be avoided except when it's absolutely necessary. Also that the function that performs the state analysis becomes a dumping ground for all sorts of poorly thought-out processing.
Those in favor of notification say that it's a cleaner model that enforces much-needed discipline on those writing the code that changes app state.
Critics of notification say that it's too complicated to implement and requires programmers to always think about updating state.
If anyone knows of any good discussions of the issues, please let me know. If you have any opinions, feel free to share.
In case anyone has some of his own input, here are some details. The UI has dropdown menus in it. The dropdown menus may look different depending on the state of the app. The simplest example is in the "Edit" menu. If the state allows the user to use the "Cut" command, then "Cut" should be enabled. Otherwise, "Cut" should be disabled. Simple enough.
It seems that the easiest option, that of having the menu itself analyze app state and take care of itself, is not feasible. Getting at certain elements of the app state is just too slow, and it makes menu dropdown sluggish.
An alternative that everyone seems to like is to have some other part of the code analyze the app state and store the results in a central object, such that a menu dropping down can go look there and take care of itself quickly. The problem then arises as to the model to use for keeping that central object up-to-date.
Some in the group want to have Windows send us a periodic message, ON_IDLE, telling us that nothing else is going on. At this point, a function would run to analyze the app state and update the central object. This is what we're calling the "polling" model, or "pulling".
Others in the group want to have the parts of the code that may affect relevant app state call into the central object at the instant that the state is changed. This is what we're calling the "notification" model, or "pushing".
Those in favor of polling say that Windows is providing this service for us, so why not use it? Also that it centralizes the code that has to perform the state analysis.
Critics of polling say that it is a model to be avoided except when it's absolutely necessary. Also that the function that performs the state analysis becomes a dumping ground for all sorts of poorly thought-out processing.
Those in favor of notification say that it's a cleaner model that enforces much-needed discipline on those writing the code that changes app state.
Critics of notification say that it's too complicated to implement and requires programmers to always think about updating state.
If anyone knows of any good discussions of the issues, please let me know. If you have any opinions, feel free to share.