| OLD | NEW |
| 1 Mojo Public API | 1 Mojo Public API |
| 2 =============== | 2 =============== |
| 3 | 3 |
| 4 The Mojo Public API is a binary stable API to the Mojo system. There are | 4 The Mojo Public API is a binary stable API to the Mojo system. |
| 5 several components to the API: | |
| 6 | 5 |
| 7 Bindings | 6 It consists of support for a number of programming languages (with a directory |
| 7 for each support language), some "build" tools and build-time requirements, and |
| 8 interface definitions for Mojo services (specified using an IDL). |
| 9 |
| 10 Note that there are various subdirectories named tests/. These contain tests of |
| 11 the code in the enclosing directory, and are not meant for use by Mojo |
| 12 applications. |
| 13 |
| 14 C/CPP/JS |
| 8 -------- | 15 -------- |
| 9 | 16 |
| 10 This directory contains a static library that clients may link into their | 17 The c/, cpp/, js/ subdirectories define the API for C, C++, and JavaScript, |
| 11 binary. The contents of this directory are not binary stable as each client is | 18 respectively. |
| 12 free to use whichever version they prefer. | |
| 13 | 19 |
| 14 This directory also contains a compiler that translates mojom interface | 20 The basic principle for these directories is that they consist of the source |
| 15 definition files into idiomatic bindings for various languages, including | 21 files that one needs at build/deployment/run time (as appropriate for the |
| 16 C++ and JavaScript. Clients are expected to statically link with the generated | 22 language), organized in a natural way for the particular language. |
| 17 code, which reads and writes the binary stable IPC message format. | |
| 18 | 23 |
| 19 Environment | 24 Interfaces |
| 20 ----------- | 25 ---------- |
| 21 | 26 |
| 22 This directory contains a static library that clients may link into their | 27 The interfaces/ subdirectory contains Mojo IDL (a.k.a. .mojom) descriptions of |
| 23 binary. The contents of this directory are not binary stable as each client is | 28 standard Mojo services. |
| 24 free to use whichever version they prefer. | |
| 25 | 29 |
| 26 The environment static library represents the shared state that is needed to | 30 Platform |
| 27 support the Bindings and GLES2 libraries. It depends on the Utility library. | 31 -------- |
| 28 | 32 |
| 29 GLES2 | 33 The platform/ subdirectory contains any build-time requirements (e.g., static |
| 34 libraries) that may be needed to produce a Mojo application for certain |
| 35 platforms, such as a native shared library or as a NaCl binary. |
| 36 |
| 37 Tools |
| 30 ----- | 38 ----- |
| 31 | 39 |
| 32 The IPC protocol used to communicate between Mojo client and the GLES2 | 40 The tools/ subdirectory contains tools that are useful/necessary at |
| 33 service is not binary stable. To insulate themselves from changes in this | 41 build/deployment time. These tools may be needed (as a practical necessity) to |
| 34 protocol, clients are expected to link dynamically against the standard GLES2 | 42 use the API in any given language, e.g., to generate bindings from Mojo IDL |
| 35 headers from Khronos and the headers in this directory, which provide an | 43 files. |
| 36 adaptor between the GLES2 C API and the underlying IPC protocol. | |
| 37 | |
| 38 System | |
| 39 ------ | |
| 40 | |
| 41 This directory defines the interface between Mojo clients and the Mojo IPC | |
| 42 system. Although the Mojo IPC message format is binary stable, the mechanism | |
| 43 by which these messages are transported is not stable. To insulate themselves | |
| 44 from changes in the underlying transport, clients are expected to link against | |
| 45 these headers dynamically. | |
| 46 | |
| 47 Tests | |
| 48 ----- | |
| 49 | |
| 50 This directory contains tests for code contained in the public API. Mojo | |
| 51 clients are expected to ignore this directory. | |
| 52 | |
| 53 Utility | |
| 54 ------- | |
| 55 | |
| 56 This directory contains a static library that clients may link into their | |
| 57 binary. The contents of this directory are not binary stable as each client is | |
| 58 free to use whichever version they prefer. | |
| 59 | |
| 60 The Utility static library most notably defines an implementation of a RunLoop | |
| 61 based on the MojoWaitMany that clients may use as the basis for asynchronous | |
| 62 message processing. | |
| OLD | NEW |