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 |