ed to the proxies if required; for example, when a developer utilizes a proxy in a way that was not originally foreseen by its creator. Utility snippets: The proxies are populated with multiple code snippets on top of the basic functionality. For example, a "Presence" proxy may have program fragment that parses the returned response (usually an XML docu- ment) for different attributes. These utilities can be suggested, in an appropri- ate manner, to developers who intend to use the proxy. Unit test code: Proxies contain codes that let different APIs supported in the proxy be tested in isolation. These are very helpful during testing and debugging. Link to blogs: Each proxy is linked to a blog entry where developers can log their experience of using the proxy. If multiple proxies are suggested during a look up, analyzing the blog entries can help the developers choose the most appropriate one for their task. 1.2.3 T-Rec Benefits Intuitively, a T-Rec proxy acts as a "wrapper" for Telecom functionality, including its underlying protocol. Using this wrapper, the proxy creator can provide several benefits to application developers. Encapsulation: APIs defined in a proxy can hide protocol-specific details from the developer. For example, interfaces in Parlay-X throw exceptions with error codes that require knowledge of Parlay-X for interpretation. As an instance, an application developer using Parlay-X would need to know that the error code SVC0004 stands for invalid addresses in a message. Using the proxy model, we can encapsulate these error codes with higher-level exceptions, such as throwing InvalidAddressException whenever error code SVC0004 is returned. Moreover, Service Composition and Control using proxies, similar APIs can be exposed across different protocols. For example, various APIs in the Location proxy can have similar signatures for Parlay-X and SIP-Presence-based implementations.* Coordination: When Telecom proxies get used in an application, the Telecom operator as well as the developer can manage and