Hi Gordon, It would be really great if we could define this API as a standard and not just specific to apache/qpid. Is there anywhere this might live? Do others think that would be important?
William ----- "Gordon Sim" <g...@redhat.com> wrote: > There has been much discussion around the need for a higher-level c++ > API that insulates an application from any protocol specific details > while allowing specific features of any given protocol to be > exploited > through the abstractions and extension points that this API offers. > > I should note that the direct use of the AMQP 0-10 specific API will > of course still be supported. > > The API I have in mind is based on the concepts of message sources > (from which messages can be received) and message sinks (to which > messages can be sent). > > To send messages on a particular session, the application obtains a > MessageProducer for that session from the chosen sink, through which > it can then send messages. To receive messages, it subscribes the > session to the chosen source. A subscription can be assoicated with a > MessageListener (for 'push' style interaction) or it can create a > MessageReceiver (for 'pull' style interactions). > > Two common patterns for sources and sinks are offered though the > Queue > and Topic classes which allow sources and sinks to be created for > named queues in a point-to-point pattern, or publish-subscribe > 'topics'. > > The attached patch offers a working sketch of such an API. The API is > currently in the qpid::client::api namespace, primarily to keep it > separate from the existing AMQP 0-10 specific API. > > There is also an implementation of this high-level API in terms of > the > existing 0-10 API in the qpid::client::amqp0_10 namespace, and a few > example programs to demonstrate the use of queues and topics > (examples/hla). > > This is still very much work in progress intended to demonstrate the > source/sink concept and how that can be mapped to different patterns > of interaction on a given protocol implementation. > > A critical aspect that I have yet to address is the nature of the > Message interface (currently this just exposes raw data with no > properties or headers). I think we also need to figure out the > common, > protocol independent options that we may want to directly support > e.g. browsing v. consuming, prefetch windows, automatic acking > v. application controlled acking etc. The threading model for > connection > processing and session dispatching also still needs to be thought > through in more detail. > > All queries, comments, criticisms etc are very welcome. > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
