Home  > 

Implementation guide

Overview

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

Entity names

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.

Data types

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.

Namespace 'proton/core'

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.

AMQP model entities

  • container
  • endpoint
  • connection
  • session
  • link
  • receiver
  • sender
  • terminus
  • condition
  • delivery
  • message

Event processing

Network and security

  • transport
  • acceptor
  • ssl
  • ssl-client-options
  • ssl-server-options
  • sasl

Error handling

Namespace 'proton/types'

Because of their centrality, the APIs here may be placed directly in the 'proton' namespace instead.

  • binary
  • boolean
  • byte
  • char
  • decimal32
  • decimal64
  • decimal128
  • double
  • duration
  • float
  • int
  • list
  • long
  • map
  • null
  • short
  • string
  • symbol
  • timestamp
  • ubyte
  • uint
  • ulong
  • url
  • ushort
  • uuid

Namespace 'proton/codec'

AMQP data encoding and decoding. These interfaces are available to the user but won't typically be necessary when building a Proton-based application.

Namespace 'proton/io'

An SPI for IO integration and a place for standard IO implementations. Like 'proton/codec', it is available but not primary.

Namespace 'proton/internal'

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.

Namespace 'proton/messenger'

A home for the legacy Messenger API.