In the interest of committing to a stable C ABI ASAP, there's a small amount of polish I want to apply to Mojo system library. This does not include the (probable) eventual rename of functions from MojoFoo to CrFoo, but when that rename is ready to happen, the Mojo API surface should correspond 1:1 with the SDK API surface I think we want.
Namely:
- Data pipe API surface will be removed [see bug 812642]
- MojoGetTimeTicksNow will be removed
- Most API functions will take a versioned "options" structure with
at least a field for flags. Destruction operations (MojoClose,
MojoDestroyMessage, MojoUnmapBuffer), MojoQueryHandleSignalsState, and
MojoGetProperty will remain excluded from this set, but all others will be
updated.
- The shared buffer API will be updated to reflect the upcoming base
SharedMemory API changes. This means removing access control flags from
MojoDuplicateBufferHandle and introducing a new MojoProtectBuffer API.
- Message manipulation is consolidated and made more ergonomical.
- MojoAttachSerializedMessageBuffer,
MojoExtendSerializedMessagePayload, and
MojoCommitSerializedMessageContents are all merged into a unified
MojoAppendMessageData call which accepts a COMMIT flag.
- MojoGetSerializedMessageContents -> MojoGetMessageData
- MojoGetMessageData gets an IGNORE_HANDLES flag to leave handles intact
- MojoAttachMessageContext -> MojoSetMessageContext
- Watchers are renamed to traps, and you add and remove "triggers"
from them rather than "contexts". Trap handler invocations are
"events" rather than "notifications". Arming a trap is a more
intuitive analogy than arming a "watcher".
Comment 1 by roc...@chromium.org
, Mar 6 2018A few more things I want to do: - Kill MojoFuseMessagePipes. This is a neat API but it severely constrains how we can implement Mojo if we ever want to replace it with something else. It has seen very little practical use and I think I can refactor all existing consumers - Reorder API function arguments to all match this basic template: F(primary-input-arguments, options-where-applicable, output-arguments)