Alan Conway wrote:
My first impression is that there are too many steps and too many
objects involved in sending/receiving messages.
Essentially there are 3 operations:
- send a message (to somewhere)
- pull a message (from somewhere)
- register a listener to have messages pushed (from somewhere)
We need to define "message" and "somewhere" in a portable way. Your
proposal addresses the "somewhere" part with sources, sinks, producers,
receivers and listeners.
The 'somewhere' part is really just covered by sources and sinks. I see
the source/sink abstractions as more than just a representation of an
'endpoint'. They can also encapsulate a 'strategy' for incoming/outgoing
message flows.
Producers, receivers and listeners are the objects through which you do
the three operations above. Sinks are 'factories' for creating producers
for a given session; sources are factories for creating receivers or
listener registrations.
I think we can compress this into fewer classes
but I don't have a proposal I'm happy with yet.
If we can make things simpler, I'm certainly all for that.
We also need to cover creating wiring,
I think the concept of creating wiring should be hidden. I think it
tends to be protocol specific and in any case is often not directly
relevant to application code.
Where a protocol requires wiring to be created for e.g. topic
subscriptions I think that should be hidden behind higher level
abstractions (such as the creation of a producer or receiver).
threading model,
I agree, we need to be more flexible here.
flow control,
and accepting/acquiring messages (browsing) etc.
My current thinking is that this sort of thing can be encapsulated as a
specific strategy for incoming or outgoing messages and therefore hidden
behind a sink/source and the producer/receiver it creates.
The sink(s)/source(s) used is/are then part of the configuration of an
application, with most of the code being entirely separated from choices
of these sorts.
I think we can evolve
rather than replace the existing API in these areas.
I don't see view this work as replacing the existing API. I think it is
simply at a higher level of abstraction.
The 0-10 specific API will still be supported and can I think be
considered stable. The initial implementation of the higher level API I
sketched out uses the 0-10 specific API that we have almost without change.
I'll keep mulling it over this week and we can sit down next week. I'll
try to make a start at cleaning up work at cleaning up the mechanics as
per my proposal - did you have any comments on it? Here it is again:
It looked good to me. I'll likely have some questions at some point. I
have tried to follow the advice with the work I did so far (in
particular using handles).
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
