qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: [c++]: Sketch of a high-level, protocol independent API
Date Wed, 15 Apr 2009 14:37:59 GMT
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-subscribe@qpid.apache.org


Mime
View raw message