Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Simplifications from ongoing discussions of namespacing

Summary

handlersLibrary of tools for event handling
PackageDescription
proton.core (alternatively, proton)Core user protocol model and utility classes
proton.eventEvent infrastructureproton.codecData encode and decodeAMQP data and frame encoding and decoding
proton.reactorsreactorLibrary of tools for IO integration, event dispatch, and event dispatchhandlers
proton.securityEncryption and authentication
proton.messengerA home for the Messenger API
proton.contribextrasExtra classes that extend core Proton functionalityproton.typesData types not supplied by the host language
proton.utilUtility classes not supplied by the host language


The 'reactors' and 'handlers' packages are expected to contain more classes over time as the number of IO integrations and event-handling behaviors grow.  By contrast, the other packages are expected to mostly stop growing once the necessary functionality is in place.
The 'event' and 'codec' packages are expected to see less mainstream usage and are therefore stowed a little further away.
The base Proton exception or error class goes in 'proton', but more specific exception types would subclasses would reside in the various subpackages above.

There are some classes we intend to deprecate or remove: Connector, Listener, Driver.

Package 'proton.core'

  • Connection, Session, Link, Terminus, Delivery, Transport, Address, Condition AMQP model objects
  • Message, Url, Security Data - Important user-facing utility classes
  • Condition, ProtonException - Core error handling

Package 'proton.event'

  • Collector, Event, EventType, EventHandler
  • Perhaps also BaseHandler and BaseReactor

Package 'proton.codec'

  • Encoder, Decoder

Package 'proton.

...

reactor'

  • Reactor, Container
  • TimestampCollector, DescribedEvent, UnsignedLongEventType, etc.EventHandler
  • MapMessagingHandler, ListIncomingMessageHandler, UuidOutgoingMessageHandler

Package 'proton.

...

security'

If reactors end up using multiple related classes, dedicated subpackages may be used here.

  • Container
  • SSL, SASL

Package 'proton.

...

messenger'

Optional.  Not every binding will include the Messenger API.

  • Messenger, SubscriptionDefaultHandler

Package 'proton.util'

These are Optional.  A place for simple extensions to the language-provided standard library.  If the utility classes can be kept private, that's better still.

  • Url

Possible subpackages

  • proton.util.logging
  • proton.util.framing

Package 'proton.messenger'

  • Messenger, Subscription

Package 'proton.contrib'

...

  • Logging classes
  • Timestamp, Described, UnsignedLong, etc. - Data types not supplied by the host language

Package 'proton.extras'

Optional.  A place for end-user extensions to the core API.

  • BlockingConnection

Changes

As of 15 September 2015, I've tried to simplify the proposed structure.

  • Removed proton.event.  Most bindings won't include this older variant of the event API.  Instead, these classes can go under proton.reactor.
  • Removed proton.types.  These are host language extensions, the same as the classes in proton.util.  Such types are moved to proton.util.
  • Moved Url and Data to proton.core.  They are part of the core user experience, across programming models.