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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
