Namespace | Content | Depends on |
---|---|---|
proton/core | AMQP model, event processing | proton/types, proton/codec, proton/io |
proton/types | AMQP data types | - |
proton/codec | AMQP data encoding and decoding | proton/types |
proton/io | An SPI for IO integration | - |
proton/internal | API internals and language extensions | - |
proton/messenger | Home of the Messenger API | proton/core |
The entity names in this document take the form 'some-entity', lower case and hyphenated. Implementers are meant to translate them into language-conventional variants.
value
or becomes Value
event_type
or EventType
url_error
or UrlError
The API should operate in terms of language-native data types whenever possible. If a type is not available in the language or its standard library, the implementer should introduce it in the 'proton/types' (or optionally 'proton') namespace.
This is the primary user entry point for the event-driven API. Most programs will import only this namespace.
Because of their centrality, the APIs here may be placed directly in the 'proton' namespace instead.
Because of their centrality, the APIs here may be placed directly in the 'proton' namespace instead.
AMQP data encoding and decoding. These interfaces are available to the user but won't typically be necessary when building a Proton-based application.
An SPI for IO integration and a place for standard IO implementations. Like 'proton/codec', it is available but not primary.
A place for anything that you happen to need in your implementation, but which you cannot make private.
These interfaces are by definition not central to the API. They should not be rendered into standard API documentation.
A home for the legacy Messenger API.