In traditional telephony, the Feature Interaction Problem (FIP) is a major concern when code for switches is developed, particularly as more features are added to particular subscriber lines. For example, Bob might have call forwarding from his home phone line to his office during work hours, but has Do Not Disturb enabled on his office phone line when a call arrives on his home line. This results in indeterminate treatment for the incoming call. In order to avoid these kinds of situations, wherever possible, phone companies used to implement careful priority rules for how particular features might work.
A more complete explanation is here: http://www2.research.att.com/~pamela/faq.html
While this problem might be mitigated somewhat in the context of a single phone line, it gets much more involved and difficult when multiple users or phone lines are involved (e.g. in the scenario from the previous paragraph). For instance, if Alice has both Call Waiting and Voice Mail features enabled on her line, a simple priority setting may be applied giving Alice up to 4 rings to pick up the waiting call, after which it is forwarded on to Voice Mail. Features in telephony switches are typically linked to triggers in the Call Model, so these can be set to work in a pre-defined priority order if there is risk of interaction.
There are several papers on this topic particularly from people who worked on the 5ESS and other switches from AT&T Bell Laboratories, long the premier Research laboratory in the world.
So why is the FIP an issue today? Let's see. In the context of Android applications or Chrome browser extensions, there are several unrelated applications a user is permitted to install and activate. Several of these might request and obtain user permission for various features including call treatment etc., unless the user is very careful, it is quite possible that indeterminate, or unexpected behavior might occur that might at best, reduce the user's delight with the use of the system, or at worst, make the system unbearably painful to use. Admittedly, this is less of a risk in the initial phases when the number of applications that utilize the more involved features supported by the user's device are available, but as these proliferate, the risks tend to rise.
Note one other thing here - in the older scenarios from traditional telephony, the location of the problem as well as the capacity to apply a fix here, were both centralized at the switch so the phone company could do these for you. This is no longer the case on the advanced smart phones of today. The issue is now localized to the smart end-point, and becomes something the end-user has to fix for themselves. And end-users tend to be far less savvy about these things than phone company Research staff tend to be. Besides, different end users have different applications installed, which might result in different feature interaction issues being manifest.
One way of minimizing these kinds of issues might be to design the APIs that developers can use such that these kinds of interactions are minimized by limiting access to particular application triggers (e.g. when apps are sleeping and waiting on a particular event to happen), or by forcing the end-user to define a priority order among these various applications on the phone. This would require a Feature Interaction Manager or FIM application to ship with the phone or as part of the smart phone operating system so that undesirable user scenarios do not occur, or their occurrence can be strictly limited to a small number of cases.
So is this all just an academic exercise at this point? Not in the least. There are several instances where adding too many extensions and enabling them all simultaneously in Chrome causes the browser to only display blank pages. No matter what URL you type, or what you do, you only see blank pages. This is debugged and fixed by turning off and then back on, extensions one at a time. This fixes the issue and makes the browser usable again. Lots of people report this issue (examples below).
Sometimes this is a result of rootkits or viruses: e.g. http://www.wintips.org/fix-google-chrome-blank-page-problem/, but other times it is resolved by turning off and on extensions as described above.
http://forums.androidcentral.com/google-nexus-7-tablet-2012/263547-blank-page-chrome.html
Since there is no easy way to fix this problem in the most general way (short of perhaps a FIM), perhaps more careful API design, developer education, and user population education that this problem exists, and how it might be addressed when it occurs, is a good way to proceed.
A more complete explanation is here: http://www2.research.att.com/~pamela/faq.html
While this problem might be mitigated somewhat in the context of a single phone line, it gets much more involved and difficult when multiple users or phone lines are involved (e.g. in the scenario from the previous paragraph). For instance, if Alice has both Call Waiting and Voice Mail features enabled on her line, a simple priority setting may be applied giving Alice up to 4 rings to pick up the waiting call, after which it is forwarded on to Voice Mail. Features in telephony switches are typically linked to triggers in the Call Model, so these can be set to work in a pre-defined priority order if there is risk of interaction.
There are several papers on this topic particularly from people who worked on the 5ESS and other switches from AT&T Bell Laboratories, long the premier Research laboratory in the world.
So why is the FIP an issue today? Let's see. In the context of Android applications or Chrome browser extensions, there are several unrelated applications a user is permitted to install and activate. Several of these might request and obtain user permission for various features including call treatment etc., unless the user is very careful, it is quite possible that indeterminate, or unexpected behavior might occur that might at best, reduce the user's delight with the use of the system, or at worst, make the system unbearably painful to use. Admittedly, this is less of a risk in the initial phases when the number of applications that utilize the more involved features supported by the user's device are available, but as these proliferate, the risks tend to rise.
Note one other thing here - in the older scenarios from traditional telephony, the location of the problem as well as the capacity to apply a fix here, were both centralized at the switch so the phone company could do these for you. This is no longer the case on the advanced smart phones of today. The issue is now localized to the smart end-point, and becomes something the end-user has to fix for themselves. And end-users tend to be far less savvy about these things than phone company Research staff tend to be. Besides, different end users have different applications installed, which might result in different feature interaction issues being manifest.
One way of minimizing these kinds of issues might be to design the APIs that developers can use such that these kinds of interactions are minimized by limiting access to particular application triggers (e.g. when apps are sleeping and waiting on a particular event to happen), or by forcing the end-user to define a priority order among these various applications on the phone. This would require a Feature Interaction Manager or FIM application to ship with the phone or as part of the smart phone operating system so that undesirable user scenarios do not occur, or their occurrence can be strictly limited to a small number of cases.
So is this all just an academic exercise at this point? Not in the least. There are several instances where adding too many extensions and enabling them all simultaneously in Chrome causes the browser to only display blank pages. No matter what URL you type, or what you do, you only see blank pages. This is debugged and fixed by turning off and then back on, extensions one at a time. This fixes the issue and makes the browser usable again. Lots of people report this issue (examples below).
Sometimes this is a result of rootkits or viruses: e.g. http://www.wintips.org/fix-google-chrome-blank-page-problem/, but other times it is resolved by turning off and on extensions as described above.
http://forums.androidcentral.com/google-nexus-7-tablet-2012/263547-blank-page-chrome.html
Since there is no easy way to fix this problem in the most general way (short of perhaps a FIM), perhaps more careful API design, developer education, and user population education that this problem exists, and how it might be addressed when it occurs, is a good way to proceed.
No comments:
Post a Comment