Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (athena.apache.org: domain of fraser.adams@blueyonder.co.uk
 designates 80.0.253.74 as permitted sender)
Message-ID: <53863B2D.8050807@blueyonder.co.uk>
Date: Wed, 28 May 2014 20:38:21 +0100
From: Fraser Adams <fraser.adams@blueyonder.co.uk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: users@qpid.apache.org
Subject: Re: AMPQ 1.0 brokerless P2P connection (qpid 0.26, proton 0.6)
References: 
 <CAGPQ6TbCJKjsJRrdBFPBFvAWOU6avpHCm7773B-C2vCigNvoKw@mail.gmail.com>
 <538450F9.5090301@redhat.com>
 <CAGPQ6TacvZ7ES+0NdCkfXvNRZcajF_xE1gHVAw-b3tWxiOAuvg@mail.gmail.com>
 <53860489.2020700@redhat.com>
In-Reply-To: <53860489.2020700@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hey Gordon,
Kind of related to this thread really, but one thing I mentioned a 
little while back was whether it'd be possible to "modularise" qpidd.

What I mean is that although clearly qpidd has been around for a while 
and is clearly a broker :-) it also contains a whole bunch of features 
that would likely be useful for any AMQP 1.0 container, being able to 
build on more general "server" style behaviour with the benefit of all 
the useful management and monitoring would be kind of cool.

I'm clearly trivialising the complexity to do such a thing, but I wonder 
whether if it was more explicitly modular then it might be easier to 
distribute the support burden (you seem to shoulder the lion's share of 
that at the moment).

I'm not suggesting that it's not actually modular at the moment, I'm 
more talking about *explicit* modularisation so that someone might be 
able to pick and choose components to use in their own application.

I clearly haven't thought about this in any great detail :-D it's more 
some idle musings, prompted by this thread, on how much of qpidd is 
genuinely "brokery" and how much is really more generally usable AMQP 
1.0 capabilities.

as I say just idle musings, I'm mostly just curious if this is something 
you've ever thought about?

cheers,
Frase


On 28/05/14 16:45, Gordon Sim wrote:
> On 05/27/2014 03:56 PM, Alexander Yakovets wrote:
>> I agree it looks like qpidmessaging.dll from qpid 0.26 with proton 
>> 0.6 do
>> not support listening for incoming connection client but maybe future
>> versions will be capable for this? Does qpid architecture suppose this
>> functionality? Or any communication via qpid::messaging API must include
>> broker?
>
> In theory it would certainly be *possible* to extend qpid::messaging 
> to allow incoming connections to be listened for and handled. Better 
> non-blcoking support would be needed as well.
>
> There is no plan as yet as to if or when this would be done however.
>
> Would the proton Messenger API meeet your needs? Note that you could 
> implement the 'server' with Messenger and the 'client(s)' with 
> qpid::messaging if desired.
>
> You may have seen my attempts to start a debate about the future 
> direction for the various APIs. If you can share any more detail about 
> what you want from an API and about your use case in general that 
> would be interesting.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org