Protocols are rules about two cooperating parties, such as a program and its underlying operating system, or a Web client and a Web server. For example, POSIX is a protocol for system service calls on the *nix platforms, and HTTP is a protocol for Web clients to access Web servers.
As with regular function/method calls, an interaction in a protocol also has its prerequisites, post-conditions, input and output. Typically a protocol will specify all these in a descriptive way, however, descriptions may contain ambiguity.
When implementing a protocol, ambiguity can lead to misunderstanding, making client and server not fully compatible. To avoid this, protocol creators always try to eliminate such ambiguities, so that program implementers can avoid such incompatibilities.
Similarly, when implementing an operating system behavior (such as creating another compatible operating system, or creating an emulation system) based on an existing operating system, the process of modeling takes a lot of effort. Behavioral compatibility is required if we want to make all depending applications run on it without issues. Otherwise, applications that expect to handle an exception in one way may see the exception in another way, and thus being unable to process it.
The happy path is relatively easy to implement--when there is no error, the logic for operating system APIs are gone through, which is straightforward. API documentation can help us implement happy paths. But for behavioral compatibility, we need to investigate the source platform behavior in error situations by experimenting. This takes a lot of effort. As a payback, through this way, applications can run reliably on the new platform.
As with regular function/method calls, an interaction in a protocol also has its prerequisites, post-conditions, input and output. Typically a protocol will specify all these in a descriptive way, however, descriptions may contain ambiguity.
When implementing a protocol, ambiguity can lead to misunderstanding, making client and server not fully compatible. To avoid this, protocol creators always try to eliminate such ambiguities, so that program implementers can avoid such incompatibilities.
Similarly, when implementing an operating system behavior (such as creating another compatible operating system, or creating an emulation system) based on an existing operating system, the process of modeling takes a lot of effort. Behavioral compatibility is required if we want to make all depending applications run on it without issues. Otherwise, applications that expect to handle an exception in one way may see the exception in another way, and thus being unable to process it.
The happy path is relatively easy to implement--when there is no error, the logic for operating system APIs are gone through, which is straightforward. API documentation can help us implement happy paths. But for behavioral compatibility, we need to investigate the source platform behavior in error situations by experimenting. This takes a lot of effort. As a payback, through this way, applications can run reliably on the new platform.
3905
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
