# Interfaces

Source: [https://docs.qualcomm.com/doc/80-41102-3/topic/concepts_interfaces.html](https://docs.qualcomm.com/doc/80-41102-3/topic/concepts_interfaces.html)

To maximize component reuse, it's vital components be designed for reuse. Reusability
            partly depends on portability, which the TelAF framework provides, but it also depends
            largely on interoperability. Reusable components must be designed for interoperability
            with as many other things as possible, including things that don't exist *-            yet!*

Interface design is the most important factor to make something interoperable.
            Standardized data types and interaction methods must be used, and the simpler the
            interfaces, the better.

TelAF embraces the philosophy that developers should always be allowed to choose the
            implementation language best suited to the task at hand, regardless of the components
            used. Some developers are better at programming in certain languages, and some languages
            are better suited to solving certain problems. That's why TelAF provides developers
            with an easy way to interface components with each other, even if they have been written
            in different languages.

A common example of a programming-language-independent interface is a networking
            protocol. But networking protocols come with pitfalls and overhead, things like endian
            issues, race conditions, protocol stack framing overheads and poor processing time.
            Networking protocols also tend to require a lot of hand coding specific to the protocol
            implementation.

TelAF supports networking, if that's what's needed, but it also has tools to implement
            much lighter-weight, language-independent communication between components that exist on
            the same host device or even running within the same process.

[Inter-process Communication](https://docs.qualcomm.com/doc/80-41102-3/topic/concepts_ipc.html)

## Function Call APIs

Virtually all programmers are familiar with function calls. While TelAF allows
                normal libraries to use their specific programming-language function call
                interfaces, TelAF also supports language-independent function call interfaces.

Using a simple interface definition language (IDL), you can create a function call
                API implemented in one language and called from another.

The implementation code (the server) can run in a different process, or even in a
                different application (in a different sandbox), than the client code that uses that
                implementation. The TelAF build system automatically generates the code needed to
                marshall parameters and return codes into messages, and send them over the IPC
                system.

See [API Files](https://docs.qualcomm.com/doc/80-41102-3/topic/api_files.html) for more information.

Last Published: Apr 23, 2025

[Previous Topic
Components](https://docs.qualcomm.com/bundle/publicresource/80-41102-3/topics/concepts_components.md) [Next Topic
Inter-process communication](https://docs.qualcomm.com/bundle/publicresource/80-41102-3/topics/concepts_ipc.md)