You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rafael Schloming <ra...@redhat.com> on 2012/07/18 18:40:40 UTC
proton: motivation and strategy
Since the start of AMQP 1.0 implementation work I've posted several
times on the design of the work as it's evolved, and a bit on the source
code layout as that work was pulled into qpid. After recent discussions
I thought it would be good to post a bit more about the motivation and
strategy behind the work and try to clear up any confusion or
uncertainty about what Proton is and what it is trying to do.
So here goes, apologies for the long and rambling nature, and please
view in a fixed width font if you want the diagram to look pretty.
--Rafael
Re: proton: motivation and strategy
Posted by Gordon Sim <gs...@redhat.com>.
On 07/19/2012 03:57 AM, Rafael Schloming wrote:
> Recasting Proton as merely a component of Qpid and denying it its own
> mailing list might be seen as a way to preclude this possibility as it
> forces Proton users to be a subset of Qpid users and Proton goals to be
> subservient to Qpid goals.
This would be entirely wrong, but I don't think that argument is
actually being made.
I haven't seen anyone that is not fully supportive of the fact that the
proton library should be usable by any application (including higher
level client libraries, brokers, bridges or end-user applications), and
should explicitly not be constrained to a supporting role for the Qpid
brokers or current client APIs.
> Unfortunately this pretty much kills the
> whole point behind Proton, which is to make it as easy as possible for
> *everyone* to speak AMQP, not just for Qpid users to speak AMQP.
Absolutely, and to me that is entirely in line with Qpid's mission. We
do not seek to have everyone use 'our' broker, or 'our' JMS client, or
'our' protocol engine for that matter. We seek to have people embrace
AMQP so that an ecosystem grows that everyone benefits from.
Now of course we build things because we want them to be useful, so it
is gratifying when people do use the components we build. But we aren't
in the business of using one component to lure people in to use others
against their will :-)
> (Note that in the previous paragraph I'm using the term Qpid to refer
> to the existing Qpid brokers and clients, not some broader notion of
> a Qpid umbrella project.)
I think Qpid was formed as what you term an umbrella project, but at the
time the nature of AMQP dictated the obvious components as being clients
and brokers. Now the possibilities have expanded. What we do might
change, why we are doing it - the mission - has not.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by Gordon Sim <gs...@redhat.com>.
On 07/19/2012 03:57 AM, Rafael Schloming wrote:
> For example the core goal of making it easy for applications to speak
> the protocol will very likely overlap with the existing client APIs
> that Qpid offers, and not everyone is comfortable with ceding that
> ground to Proton, or letting there be some amount of overlap.
I think 'ceding ground' is the wrong way to look at this, if this is
indeed a view held by some.
I think your notes explained well how the understanding of the API space
has improved and deepened as Proton has developed. I myself have asked
questions around that, and on how it impacts the existing APIs which
were after all developed specifically to support transition to AMQP 1.0.
However asking questions is not opposing anything. We would be foolish
to refuse to act upon better understanding of the problem space. That
would not be serving the interests of our users. I am fully prepared to
consider how the messaging API might evolve or might ultimately be
replaced. At this point it seems to me though that we simply need to
discuss the ideas more and start including users in those discussions.
We should not let the past constrain the future. We do however have an
obligation to our users to have an open dialogue about changes and to
collectively seek to make those smooth. That is true for all aspects and
will be true for proton itself as it evolves.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by Rafael Schloming <ra...@redhat.com>.
On Wed, 2012-07-18 at 16:43 -0400, Rajith Attapattu wrote:
> First of all, we as a community needs to collectively decide what our
> charter is and more importantly *HOW TO GET THERE*.
> While the majority *agrees* that our charter is "promoting the
> adoption of AMQP and being the premier ecosystem for AMQP", there
> seems *varying degrees of disagreements* on how to get there.
>
> Therefore we need to have that discussion. BUT lets not use that to
> hold up the progress of Proton either.
>
> Arguing for or against, whether we should do this, under the same
> project, a two headed project or two separate TLP's at this point
> might be a distraction for Proton.
To be clear I wasn't actually proposing any one of those or suggesting
that we need to decide one now. I'm actually fairly relaxed about how
Qpid is organized overall so long as Proton is free to pursue its
mission. The options I documented are all actually viewpoints that have
been expressed to me by other Qpid developers. My first thought was that
it would help to put the Proton mission, strategy, and scope down in
words so that we would at least all have a common understanding of what
is meant when someone says "Proton". However, after writing the document
I came to the conclusion that peoples view of Qpid actually varies far
more than anyone's view of Proton.
> For now we all agree that Proton is a separate body of work, and it's
> in a rapid growth stage.
> We all agree that it's an important piece of work. Therefore we need
> to ensure we progress on Proton.
> A separate mailing-list and a JIRA instance is not unreasonable.
> Mailing lists can be renamed, folded, deleted ..etc.
> These pieces of infrastructure doesn't necessarily define the scope,
> or mean we are deciding on the above argument.
> **Projects are defined by the community, not pieces of infrastructure.
> We need to understand that.**
This is partly conjecture and partly based on some of what I've heard
from other people off-list, but I think the issue some people have with
a separate mailing list is that they are concerned that if Proton is
allowed its own mailing list then its users will draw it in a direction
that might not be consistent with the current set of Qpid users. For
example the core goal of making it easy for applications to speak the
protocol will very likely overlap with the existing client APIs that
Qpid offers, and not everyone is comfortable with ceding that ground to
Proton, or letting there be some amount of overlap.
Recasting Proton as merely a component of Qpid and denying it its own
mailing list might be seen as a way to preclude this possibility as it
forces Proton users to be a subset of Qpid users and Proton goals to be
subservient to Qpid goals. Unfortunately this pretty much kills the
whole point behind Proton, which is to make it as easy as possible for
*everyone* to speak AMQP, not just for Qpid users to speak AMQP. (Note
that in the previous paragraph I'm using the term Qpid to refer to the
existing Qpid brokers and clients, not some broader notion of a Qpid
umbrella project.)
This unfortunately ties the mailing list issue into the organizational
one so long as people see the former as a way to influence the latter.
--Rafael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, Jul 19, 2012 at 10:59 AM, Gordon Sim <gs...@redhat.com> wrote:
> On 07/18/2012 09:43 PM, Rajith Attapattu wrote:
>>
>> 1. What do we want the Qpid brand name to be associated with ? is it
>> AMQP in general or is it the clients/brokers ?
>> 2. What are we going to do with our current set of brokers ? will they
>> be there in the future ?
>> 3. What are we going to do with the Messaging API ?
>> 4. What are we going to do with JMS and WCF?
>> 5. What are we going to do with QMF ?
>> 6. What are we going to offer as products/services going forward ?
>
>
> Good questions! My own answers at present would be:
I really like your answers! Sensible and certainly food for thought.
> 1. To me Qpid is about AMQP infrastructure at Apache. It is not limited to
> clients/brokers. (And in any case proton is evolving to be a client as well)
>
> 2. This is probably the hardest one for me to answer.
>
> As mentioned (more than once, sorry!) I do believe there is a great deal of
> value in an AMQP focused broker at Apache, and to me Qpid is currently the
> obvious place for that given our charter and our history.
>
> However I think there has long been some concern around the duplication of
> effort between the two current Qpid brokers and the confusion that arises
> from having them both.
>
> I don't think it is sensible to continue to maintain more than one broker
> targeted at the same use cases.
>
> In addition I think the evolution of the protocol has freed us from what I
> see as the somewhat flawed model pushed by earlier versions. It also opens
> up new possibilities.
>
> So though I don't have any concrete proposal, I think it would make sense to
> transition to one broker or to clearly distinguish different classes of
> broker if that seems preferable on further analysis. I think this would be
> an area where we should see if we can revisit collaboration with the
> ActiveMQ project in some guise.
>
> There may emerge some distinct cases that I have heard talked about as
> 'routers' rather than brokers.
I have long been a supporter of a single broker to better utilize our resources.
There is no point having 2 different brokers that does more or less
the same thing.
However I agree there can be different "classes" of brokers. I will
not delve too much into details here, as this not the right forum for
that.
As Gordon said we should be brave enough to make rational decisions
and not let the past constrain us.
Besides this will free us to explore new and interesting things.
> 3. This is the second hardest question for me!
>
> I've personally invested a lot of time and effort in the qpid messaging API.
> It was specifically geared to transitioning to 1.0. I personally feel there
> is much to recommend it still. My desire would be to find a way for this to
> 'blend in' with the APIs developing under proton in some way.
>
> However I agree with Rafi's analysis of the different facets of use; I find
> his account of the evolution of proton in this respect compelling. I think
> it would be foolish to stick rigidly to the past despite a deeper, richer
> understanding of the API space emerging.
>
> I believe that what users really want is not 4 entirely separate APIs, but
> something that transitions from one use case to another more smoothly.
> Ideally I don't want to have to learn all 4 APIs to see which one best fits
> my requirements; ideally I don't want a new requirement in my system to
> force me onto an entirely different API.
>
> I think there are still some open questions here. I think the the proton
> APIs are very new and may still evolve a little (the engine less so, the
> driver and messenger APIs more so). We need more user involvement and open
> discussion of options. I hope to have more time in the not too distant
> future to collaborate on some of this.
I think with more time and exposure we will get more clarity here.
All though we don't have all the answers yet, we should ensure we
continue to have an open & transparent discussion on this, until we
get those answers.
We also need to ensure we 'take care' of existing users who have
invested in these API's.
(I believe Gordon made more or less the same point).
> 4. I think an open AMQP enabled JMS client is very valuable. I think we
> should continue to offer one and it should be based on proton-j.
The JMS client and the JCA adapter have proven to be an easy entry
point for existing users to step into the AMQP world with little
impact to their existing applications. We should continue to maintain
this advantage !.
> In theory I think WCF is also useful. In practice we don't at present have
> the developer- or user- base to effectively address that in my view, but if
> we did I would be very much in favour of it. In other words I think it is a
> valuable contribution to our mission if and when we have the demand and the
> ability to support that demand.
Agreed!
> 5. I think a message-based scheme for managing brokers (and indeed perhaps
> other AMQP entities) is very valuable. I believe that there is to me some
> effort to start standardising such a mechanism on top of AMQP 1.0. In any
> case QMF as it is needs to adapt to 1.0 and still has a few warts I'd like
> to get rid of.
Agreed.
> 6. As above, there may be such a thing as a 'router', distinct from a
> 'broker'. At this point that is in my mind at least simply a nice concept,
> without sufficient substance but perhaps one for future
> thinking/development.
>
> I also think some bridges to other protocols could be useful.
+1.
Rajith
> However I think we should try to prioritise and I think as the foundation of
> all of this, proton is really the top priority for new development in my
> eyes.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by Rafael Schloming <ra...@redhat.com>.
On Thu, 2012-07-19 at 15:59 +0100, Gordon Sim wrote:
> 3. This is the second hardest question for me!
>
> I've personally invested a lot of time and effort in the qpid messaging
> API. It was specifically geared to transitioning to 1.0. I personally
> feel there is much to recommend it still. My desire would be to find a
> way for this to 'blend in' with the APIs developing under proton in some
> way.
>
> However I agree with Rafi's analysis of the different facets of use; I
> find his account of the evolution of proton in this respect compelling.
> I think it would be foolish to stick rigidly to the past despite a
> deeper, richer understanding of the API space emerging.
>
> I believe that what users really want is not 4 entirely separate APIs,
> but something that transitions from one use case to another more
> smoothly. Ideally I don't want to have to learn all 4 APIs to see which
> one best fits my requirements; ideally I don't want a new requirement in
> my system to force me onto an entirely different API.
I agree. The matrix is really describing use cases and ideally a single
API or a small suite of integrated APIs could address all 4 quadrants.
There is definitely a certain level of integration with what's there
now, e.g. there is a common message abstraction that can be used across
both messenger and the engine. I think this will definitely evolve
though.
> I think there are still some open questions here. I think the the proton
> APIs are very new and may still evolve a little (the engine less so, the
> driver and messenger APIs more so). We need more user involvement and
> open discussion of options. I hope to have more time in the not too
> distant future to collaborate on some of this.
That would be excellent.
--Rafael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by Gordon Sim <gs...@redhat.com>.
On 07/20/2012 06:41 PM, Rafael Schloming wrote:
> On Fri, 2012-07-20 at 11:20 +0100, Gordon Sim wrote:
>> On 07/19/2012 07:03 PM, Alan Conway wrote:
>>> On the blocking front, a good messaging API should support both blocking
>>> and non-blocking use. The messaging API can certainly be extended in a
>>> backward compatible way to do so.
>>
>> Yes, I agree.
>>
>>> On the easy-to-use front it seems to me that the ideal is the an easy
>>> messaging API layered over a full-control proton API, where the
>>> underlying proton API can be exposed for "advanced" users or ignored by
>>> normal users.
>>
>> I think there are perhaps more than two levels of ease of use. At the
>> very 'top' level, you just care about sending and receiving with no
>> interest in connections, sessions, sender or receivers. The 'bottom'
>> level is full protocol control. The messaging API at present is
>> somewhere between those.
>
> I don't actually think of the "Limited" column of the matrix, or any of
> the others as expressing easy vs hard. The matrix is classifying what it
> is you want/need to be able to do, not how hard it is to do it. Ideally
> functionality in every quadrant should be as easy to use as possible.
Agreed, I should not have used the term 'ease of use'. Its really about
the level of abstraction from the protocol interaction.
> Given that it's describing functionality, you could certainly define
> more columns based on a finer grained look at the protocol features that
> are available, and indeed there are different aspects to the two
> programming models that may ultimately make sense to call out into
> different rows. What I've included represents the extreme ends of the
> spectrum in each dimension, as that's where initial work has been
> focused in order to ensure the necessary flexibility.
Right, the most limited set of functionality that still makes sense is
simple sending and receiving messages (no explicit connections,
sessions, senders, receivers).
At the other end of the spectrum you have full control over all aspects
supported by the protocol.
In some ways there is increasing 'functionality' as you move away from
direct interaction with the protocol. E.g connection pooling, perhaps
transparent replay etc, However you also get less control over the
protocol, which may in itself be a loss of some functionality.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by Rafael Schloming <ra...@redhat.com>.
On Fri, 2012-07-20 at 11:20 +0100, Gordon Sim wrote:
> On 07/19/2012 07:03 PM, Alan Conway wrote:
> > On the blocking front, a good messaging API should support both blocking
> > and non-blocking use. The messaging API can certainly be extended in a
> > backward compatible way to do so.
>
> Yes, I agree.
>
> > On the easy-to-use front it seems to me that the ideal is the an easy
> > messaging API layered over a full-control proton API, where the
> > underlying proton API can be exposed for "advanced" users or ignored by
> > normal users.
>
> I think there are perhaps more than two levels of ease of use. At the
> very 'top' level, you just care about sending and receiving with no
> interest in connections, sessions, sender or receivers. The 'bottom'
> level is full protocol control. The messaging API at present is
> somewhere between those.
I don't actually think of the "Limited" column of the matrix, or any of
the others as expressing easy vs hard. The matrix is classifying what it
is you want/need to be able to do, not how hard it is to do it. Ideally
functionality in every quadrant should be as easy to use as possible.
Given that it's describing functionality, you could certainly define
more columns based on a finer grained look at the protocol features that
are available, and indeed there are different aspects to the two
programming models that may ultimately make sense to call out into
different rows. What I've included represents the extreme ends of the
spectrum in each dimension, as that's where initial work has been
focused in order to ensure the necessary flexibility.
--Rafael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by Gordon Sim <gs...@redhat.com>.
On 07/19/2012 07:03 PM, Alan Conway wrote:
> On the blocking front, a good messaging API should support both blocking
> and non-blocking use. The messaging API can certainly be extended in a
> backward compatible way to do so.
Yes, I agree.
> On the easy-to-use front it seems to me that the ideal is the an easy
> messaging API layered over a full-control proton API, where the
> underlying proton API can be exposed for "advanced" users or ignored by
> normal users.
I think there are perhaps more than two levels of ease of use. At the
very 'top' level, you just care about sending and receiving with no
interest in connections, sessions, sender or receivers. The 'bottom'
level is full protocol control. The messaging API at present is
somewhere between those.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by Carl Trieloff <cc...@redhat.com>.
On 07/20/2012 04:03 PM, William Henry wrote:
> So to the folks that make decisions on this list:
> Is AMQP more important than "legacy" Qpid?
> Is proton about AMQP 1.0 or about "legacy" Qpid?
Nice summary,
a.) I would say Proton is about making it easy for anyone to use AMQP 1.0
b.) In so doing it should naturally be the best solution to help Qpid
(Broker and Clients / API etc) get to AMQP 1.0
I don't think we need to over think it. I would expect over time we may
land up with broker, clients, proton, qmf etc subprojects under Qpid.
Carl.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by William Henry <wh...@redhat.com>.
Wow that was some thread! Sorry I'm not going to respond to any specific part but the overall themes.
It seems there are two higher level threads:
1. What about proton and where is it's future?
2. What about legacy Qpid and how does proton effect it?
And that is really how it should be.
The questions we should be asking to figure out the answers to the above are:
Is AMQP more important than "legacy" Qpid?
Is proton about AMQP 1.0 or about "legacy" Qpid? (migrating Qpid to AMQP 1.0)
AMQP and it's broad adoption is the most important. Proton is all about AMQP 1.0 and therefore it is critical to the expansion and adoption of AMQP.
Legacy Qpid is also very important but in a different way.
Qpid was traditionally about AMQP in terms of the broker. Since AMQP 1.0 the exchange/queue broker model is less important but still VERY important as a specific AMQP solution for many users.
(Before anyone gets on my case I will also say that legacy Qpid is also about the Messaging API and that is also very very important!)
I'm not sure how best these projects get homed in terms of projects in ASF or otherwise but some thoughts/observations:
Proton, as a library that helps adoption of AMQP 1.0, should not be held back by legacy Qpid.
Proton itself will evolve and is already doing so by the fact that ActiveMQ is already consuming it. And that's how we want this to happen. If so called "competitors" (and I don't necessarily mean ActiveMQ) are consuming proton that's a good thing, and it's also beyond our control. Proton can be consumed and will be consumed (hopefully) by other projects. Great! Excellent! Go AMQP 1.0. Go proton. It's a wonderful thing if proton becomes the de facto library for advancement of AMQP.
What about legacy Qpid? What about brokers in general?
Once "we" put out proton that all became a very different conversation. The tail wagging the dog.
I see a place where there are AMQP (proton) based solutions. I don't see one broker. I do see consolidation of effort but I see different solutions. Perhaps some part of the community continues to invest time and effort in a C/C++ based broker that solves a specific problem. Perhaps the ActiveMQ based broker solves another class of problems. Perhaps some new "fashionable" project gets started somewhere else (or at Qpid) that solves a different "routing" problem. Perhaps someone develops a new language API at Qpid. Maybe someone in Mozilla builds a AMQP plugin using proton. Proton has let the cat out of the bag. IF we try to reign it in we might lose some very good momentum for AMQP.
What we don't want to happen is that the current Qpid broker "product" or solution should hold back what proton can potentially do best: drive wider and faster AMQP adoption. qpid.apache.org can still be a home for many AMQP based solutions and could presumably still be a home to proton.
BUT if qpid.apache.org could/would hold back proton then we have to consider if it is wiser to somehow separate the efforts in some way (mailing list or otherwise). By the way, that's little different than it already is today.
So to the folks that make decisions on this list:
Is AMQP more important than "legacy" Qpid?
Is proton about AMQP 1.0 or about "legacy" Qpid?
Can Proton live at Qpid and NOT be held back by legacy Qpid? What's best for Proton and AMQP in general?
Best regards,
William
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by Rafael Schloming <ra...@redhat.com>.
On Thu, 2012-07-19 at 14:03 -0400, Alan Conway wrote:
> On Thu, 2012-07-19 at 15:59 +0100, Gordon Sim wrote:
> >
> > I've personally invested a lot of time and effort in the qpid messaging
> > API. It was specifically geared to transitioning to 1.0. I personally
> > feel there is much to recommend it still. My desire would be to find a
> > way for this to 'blend in' with the APIs developing under proton in some
> > way.
> >
> > However I agree with Rafi's analysis of the different facets of use; I
> > find his account of the evolution of proton in this respect compelling.
> > I think it would be foolish to stick rigidly to the past despite a
> > deeper, richer understanding of the API space emerging.
> >
> > I believe that what users really want is not 4 entirely separate APIs,
> > but something that transitions from one use case to another more
> > smoothly. Ideally I don't want to have to learn all 4 APIs to see which
> > one best fits my requirements; ideally I don't want a new requirement in relat
> > my system to force me onto an entirely different API.
> >
>
> Rafi's axes were blocking/non-blocking and
> easy-to-use/full-control-of-protocol.
>
> On the blocking front, a good messaging API should support both blocking
> and non-blocking use. The messaging API can certainly be extended in a
> backward compatible way to do so.
>
> On the easy-to-use front it seems to me that the ideal is the an easy
> messaging API layered over a full-control proton API, where the
> underlying proton API can be exposed for "advanced" users or ignored by
> normal users.
As I mentioned in my reply to Gordon, I don't think of the "Limited"
column meaning easy-to-use per/se (although there is obviously some
correlation), I would think easy vs hard probably maps as much to the
blocking vs non blocking rows, since often people find non-blocking
difficult. The key difference in the columns is exposure to the low
level details of what's going on.
The interface to the messenger API is pretty much just:
send(global-address, message)
The messenger implementation will under the covers open the necessary
connections, sessions, and links required to deliver the messages you
pass to it. In interface it's very much like the sendmail program,
except it's a lot smarter and more powerful since it does pooling and
what not behind the scenes, and of course it can receive messages in a
similar way as well with global subscriptions. This is obviously a very
different paradigm from say the messaging API or the engine where you
have explicit control over exactly what connections, sessions, and links
are created and you manage them all yourself.
This is why I suspect a complete implementation of the feature space
within the matrix may actually be a small suite of integrated APIs
rather than a single API. It's hard to imagine a single API that will do
both what messenger does and what messaging does, but it's easy and
quite useful for both those APIs to use the same message abstraction.
--Rafael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by Alan Conway <ac...@redhat.com>.
On Thu, 2012-07-19 at 15:59 +0100, Gordon Sim wrote:
>
> I've personally invested a lot of time and effort in the qpid messaging
> API. It was specifically geared to transitioning to 1.0. I personally
> feel there is much to recommend it still. My desire would be to find a
> way for this to 'blend in' with the APIs developing under proton in some
> way.
>
> However I agree with Rafi's analysis of the different facets of use; I
> find his account of the evolution of proton in this respect compelling.
> I think it would be foolish to stick rigidly to the past despite a
> deeper, richer understanding of the API space emerging.
>
> I believe that what users really want is not 4 entirely separate APIs,
> but something that transitions from one use case to another more
> smoothly. Ideally I don't want to have to learn all 4 APIs to see which
> one best fits my requirements; ideally I don't want a new requirement in relat
> my system to force me onto an entirely different API.
>
Rafi's axes were blocking/non-blocking and
easy-to-use/full-control-of-protocol.
On the blocking front, a good messaging API should support both blocking
and non-blocking use. The messaging API can certainly be extended in a
backward compatible way to do so.
On the easy-to-use front it seems to me that the ideal is the an easy
messaging API layered over a full-control proton API, where the
underlying proton API can be exposed for "advanced" users or ignored by
normal users.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Hi,
On Thu, Jul 19, 2012 at 10:59 AM, Gordon Sim <gs...@redhat.com> wrote:
>
> 2. This is probably the hardest one for me to answer.
>
> As mentioned (more than once, sorry!) I do believe there is a great deal
> of value in an AMQP focused broker at Apache, and to me Qpid is currently
> the obvious place for that given our charter and our history.
>
> However I think there has long been some concern around the duplication of
> effort between the two current Qpid brokers and the confusion that arises
> from having them both.
>
> I don't think it is sensible to continue to maintain more than one broker
> targeted at the same use cases.
>
> In addition I think the evolution of the protocol has freed us from what I
> see as the somewhat flawed model pushed by earlier versions. It also opens
> up new possibilities.
>
> So though I don't have any concrete proposal, I think it would make sense
> to transition to one broker or to clearly distinguish different classes of
> broker if that seems preferable on further analysis. I think this would be
> an area where we should see if we can revisit collaboration with the
> ActiveMQ project in some guise.
>
Yay!
>
> In theory I think WCF is also useful. In practice we don't at present have
> the developer- or user- base to effectively address that in my view, but if
> we did I would be very much in favour of it. In other words I think it is a
> valuable contribution to our mission if and when we have the demand and the
> ability to support that demand.
>
>
And on the topic of WCF, if your going to be implementing a JMS client,
implementing an NMS [1] client would be nice too. That ways .NET folks can
easily switch from ActiveMQ's or Tibco's protocol to AMQP. The NMS apis
already kinda popular in the .NET world when folks are interested in
maintaining some vender neutrality.
[1]: http://activemq.apache.org/nms/
Yes this probably one of those projects like Proton which would
have benefitted from being a TLP to avoid folks thinking it's ActiveMQ
specific.
--
**
*Hiram Chirino*
*Software Fellow | FuseSource Corp.*
*chirino@fusesource.com | fusesource.com*
*skype: hiramchirino | twitter: @hiramchirino<http://twitter.com/hiramchirino>
*
*blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*
*
*
*
*
Re: proton: motivation and strategy
Posted by Gordon Sim <gs...@redhat.com>.
On 07/18/2012 09:43 PM, Rajith Attapattu wrote:
> 1. What do we want the Qpid brand name to be associated with ? is it
> AMQP in general or is it the clients/brokers ?
> 2. What are we going to do with our current set of brokers ? will they
> be there in the future ?
> 3. What are we going to do with the Messaging API ?
> 4. What are we going to do with JMS and WCF?
> 5. What are we going to do with QMF ?
> 6. What are we going to offer as products/services going forward ?
Good questions! My own answers at present would be:
1. To me Qpid is about AMQP infrastructure at Apache. It is not limited
to clients/brokers. (And in any case proton is evolving to be a client
as well)
2. This is probably the hardest one for me to answer.
As mentioned (more than once, sorry!) I do believe there is a great deal
of value in an AMQP focused broker at Apache, and to me Qpid is
currently the obvious place for that given our charter and our history.
However I think there has long been some concern around the duplication
of effort between the two current Qpid brokers and the confusion that
arises from having them both.
I don't think it is sensible to continue to maintain more than one
broker targeted at the same use cases.
In addition I think the evolution of the protocol has freed us from what
I see as the somewhat flawed model pushed by earlier versions. It also
opens up new possibilities.
So though I don't have any concrete proposal, I think it would make
sense to transition to one broker or to clearly distinguish different
classes of broker if that seems preferable on further analysis. I think
this would be an area where we should see if we can revisit
collaboration with the ActiveMQ project in some guise.
There may emerge some distinct cases that I have heard talked about as
'routers' rather than brokers.
3. This is the second hardest question for me!
I've personally invested a lot of time and effort in the qpid messaging
API. It was specifically geared to transitioning to 1.0. I personally
feel there is much to recommend it still. My desire would be to find a
way for this to 'blend in' with the APIs developing under proton in some
way.
However I agree with Rafi's analysis of the different facets of use; I
find his account of the evolution of proton in this respect compelling.
I think it would be foolish to stick rigidly to the past despite a
deeper, richer understanding of the API space emerging.
I believe that what users really want is not 4 entirely separate APIs,
but something that transitions from one use case to another more
smoothly. Ideally I don't want to have to learn all 4 APIs to see which
one best fits my requirements; ideally I don't want a new requirement in
my system to force me onto an entirely different API.
I think there are still some open questions here. I think the the proton
APIs are very new and may still evolve a little (the engine less so, the
driver and messenger APIs more so). We need more user involvement and
open discussion of options. I hope to have more time in the not too
distant future to collaborate on some of this.
4. I think an open AMQP enabled JMS client is very valuable. I think we
should continue to offer one and it should be based on proton-j.
In theory I think WCF is also useful. In practice we don't at present
have the developer- or user- base to effectively address that in my
view, but if we did I would be very much in favour of it. In other words
I think it is a valuable contribution to our mission if and when we have
the demand and the ability to support that demand.
5. I think a message-based scheme for managing brokers (and indeed
perhaps other AMQP entities) is very valuable. I believe that there is
to me some effort to start standardising such a mechanism on top of AMQP
1.0. In any case QMF as it is needs to adapt to 1.0 and still has a few
warts I'd like to get rid of.
6. As above, there may be such a thing as a 'router', distinct from a
'broker'. At this point that is in my mind at least simply a nice
concept, without sufficient substance but perhaps one for future
thinking/development.
I also think some bridges to other protocols could be useful.
However I think we should try to prioritise and I think as the
foundation of all of this, proton is really the top priority for new
development in my eyes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by Rajith Attapattu <ra...@gmail.com>.
First of all, we as a community needs to collectively decide what our
charter is and more importantly *HOW TO GET THERE*.
While the majority *agrees* that our charter is "promoting the
adoption of AMQP and being the premier ecosystem for AMQP", there
seems *varying degrees of disagreements* on how to get there.
Therefore we need to have that discussion. BUT lets not use that to
hold up the progress of Proton either.
Arguing for or against, whether we should do this, under the same
project, a two headed project or two separate TLP's at this point
might be a distraction for Proton.
For now we all agree that Proton is a separate body of work, and it's
in a rapid growth stage.
We all agree that it's an important piece of work. Therefore we need
to ensure we progress on Proton.
A separate mailing-list and a JIRA instance is not unreasonable.
Mailing lists can be renamed, folded, deleted ..etc.
These pieces of infrastructure doesn't necessarily define the scope,
or mean we are deciding on the above argument.
**Projects are defined by the community, not pieces of infrastructure.
We need to understand that.**
Let Proton or any other project/sub-project grow organically, and
sooner or later it will provide the answers to the above debate.
So lets not put the cart before the horse. Lets not get into an
argument over how things should be structured (yet).
Instead lets support Proton to achieve it's goal of being "The
opensource library for AMQP".
This goal is perfectly complimentary to our original Qpid charter.
In the meantime, lets continue the discussion (openly and
transparently) on how we want to achieve our charter/mission/goals.
There are several questions that we ought to decide for ourselves and
for our users/customers.
Especially as a community we need to provide some answers to our users.
(Answers to these are best discussed on a separate thread. )
1. What do we want the Qpid brand name to be associated with ? is it
AMQP in general or is it the clients/brokers ?
2. What are we going to do with our current set of brokers ? will they
be there in the future ?
3. What are we going to do with the Messaging API ?
4. What are we going to do with JMS and WCF?
5. What are we going to do with QMF ?
6. What are we going to offer as products/services going forward ?
We might not have all the answers as a lot of pieces are in flux.
But at least lets keep the discussion going to figure out what we need
to do get those answers.
Regards,
Rajith
On Wed, Jul 18, 2012 at 12:40 PM, Rafael Schloming <ra...@redhat.com> wrote:
> Since the start of AMQP 1.0 implementation work I've posted several
> times on the design of the work as it's evolved, and a bit on the source
> code layout as that work was pulled into qpid. After recent discussions
> I thought it would be good to post a bit more about the motivation and
> strategy behind the work and try to clear up any confusion or
> uncertainty about what Proton is and what it is trying to do.
>
> So here goes, apologies for the long and rambling nature, and please
> view in a fixed width font if you want the diagram to look pretty.
>
> --Rafael
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by Carl Trieloff <cc...@redhat.com>.
On 07/18/2012 02:05 PM, Gordon Sim wrote:
> On 07/18/2012 05:40 PM, Rafael Schloming wrote:
>> So while the Proton mission is in many ways compatible with the
>> original Qpid charter, the de facto Qpid mission of today is really
>> quite different from Proton's.
>
> I tend to disagree.
>
> In my mind, the purpose of Qpid has always been to develop software
> under the ASF governance and licensing in order to support adoption of
> AMQP and the emergence of an ecosystem built around it that better
> serves users needs.
>
> At the time Qpid was formed, that meant client libraries and messaging
> brokers. We have always wanted to have embeddable libraries that other
> broker/clients/frameworks/etc could use to support AMQP however.
>
> As AMQP has evolved, a clearer, cleaner layering has emerged. The
> specification defines how different components can interoperate,
> rather than attempting to define the behaviour an interchangeable
> message broker (which the earlier specifications did not in fact
> achieve anyway).
>
> In addition I think through developing and maintaining different
> language implementations we have come to appreciate ways in which this
> can be kept more manageable for maintainers and less confusing for end
> users.
>
> The landscape is therefore different now than it was when Qpid began.
> To my mind however the mission of the project is not, though we should
> always be prepared as a community to re-evaluate how best to achieve it.
>
> I believe wholeheartedly in the development of a protocol engine for
> the three 'platforms' mentioned (C, Java and JavaScript). I believe
> these should be usable by any higher level component that wants to
> speak AMQP in some way, whether part of Qpid or not.
>
> It seems clear there is also opportunity for wide reuse of a 'driver'
> - an IO subsystem as you put it - designed to work well with the
> engine, for cases where that functionality is not already provided.
>
> I also fully appreciate and welcome the expanded understanding of the
> 'API space' that these developments have brought into focus, though I
> think there is still some thinking to be done there.
>
> As I stated on another thread, I think we need a shift in emphasis. A
> renewed emphasis on interoperability, a new emphasis on enabling an
> ecosystem that is wider than perhaps first imagined.
>
> To my mind this is not a change to the mission or Qpid, nor does not
> necessarily negate the value of existing components (though again, we
> should never be afraid to re-evaluate).
>
> An ASF governed, open, AMQP enabled JMS client is clearly a valuable
> piece of the 1.0 ecosystem, as is a broker that can support the full
> functionality that JMS defines. These should likewise be usable on
> their own, against AMQP-enabled components developed outside Qpid, and
> outside the ASF. They play a different role than proton in promoting
> AMQP, but in my view are merely different initiatives supporting the
> same mission.
>
> I anticipate new behaviours and components that can be built on top of
> the core AMQP protocol in the future and what better place to explore
> and develop those than here at Qpid, under an established, well
> respected governance model? I think we also have a responsibility, and
> perhaps a unique position, to help bridge users of the earlier
> revisions of AMQP onto the better world that 1.0 promises, the users
> that in large part have fuelled that very evolution of the specification.
>
> What structuring makes most sense is something I think will become
> clearer organically as we make progress. The key is - as always! -
> continual, open communication and debate, not only amongst the
> developers but with users in the widest sense.
>
> There is much to do! Let's get on and do it, remembering all the while
> to talk about what we are doing and be open and welcoming to all who
> wish to collaborate.
I agree with Gordon here,
Carl.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Thu, Jul 19, 2012 at 08:23:14AM -0400, Rafael Schloming wrote:
> While both of these fall under the very broad remit of promoting
> adoption of AMQP, it simply doesn't work to mix the two strategies
> within the same project with no delineation. If you do you're
> essentially asking people to embed their competitor's component into
> their broker so that their users can more easily migrate over to the
> competition.
Remember Palm and their business model? It's a good analogy to remember
how they tried to produce both the software for OEMs but also handsets
that competed with the OEMs. They fragmented their own market and it
destroyed them when a viable alternative came along.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: proton: motivation and strategy
Posted by Gordon Sim <gs...@redhat.com>.
On 07/19/2012 01:23 PM, Rafael Schloming wrote:
> The fundamental issue is that there are at least two ways to promote
> adoption of AMQP: either via competition, e.g. building a broker that
> happens to speak AMQP and competes with existing brokers; or via
> cooperation, e.g. building a library to make it easy for any existing
> broker to speak AMQP.
I don't accept that view.
I believe our mission is to provide useful components under an ASF
license, developed through an ASF governed process in order to ensure
that there is truly open, freely usable AMQP infrastructure for anyone
who wants it.
I don't accept that based on which component I help to develop I am
choosing between cooperation and competition. I believe in all
components I would be choosing collaboration and committing to
interoperability.
> While both of these fall under the very broad remit of promoting
> adoption of AMQP, it simply doesn't work to mix the two strategies
> within the same project with no delineation.
I think the components are very clearly delineated. That was the whole
purpose of the proposed svn structure that is now in place.
As we have commented on already, there is some overlap in role between
the existing qpid messaging API and the evolving proton APIs. It makes
sense to continue to explore that and hopefully reach a resolution that
serves the interests of all users.
> If you do you're
> essentially asking people to embed their competitor's component into
> their broker so that their users can more easily migrate over to the
> competition.
I disagree. Were that argument true it would undermine the premise of
AMQP in my view. AMQP allows me to take one component from one source
and having it work together with another component from another source.
Picking a Qpid client does not require you to pick a Qpid broker and
vice versa.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by Rafael Schloming <ra...@redhat.com>.
On Thu, 2012-07-19 at 07:52 +0200, Rob Godfrey wrote:
> I'm about to head out on vacation for 10 days or so, and haven't had a
> chance to read Rafi's document yet, but for the avoidance of doubt I'd
> just like to make clear that I completely concur with the position
> Gordon outlined below.
> > In my mind, the purpose of Qpid has always been to develop software under
> > the ASF governance and licensing in order to support adoption of AMQP and
> > the emergence of an ecosystem built around it that better serves users
> > needs.
>
> Proton is a (big) part of that effort in my mind, and I think our
> ability to contribute to the success of AMQP 1.0 would be (stupidly,
> unnecessarily) harmed by diluting our efforts into different
> "projects".
The fundamental issue is that there are at least two ways to promote
adoption of AMQP: either via competition, e.g. building a broker that
happens to speak AMQP and competes with existing brokers; or via
cooperation, e.g. building a library to make it easy for any existing
broker to speak AMQP.
While both of these fall under the very broad remit of promoting
adoption of AMQP, it simply doesn't work to mix the two strategies
within the same project with no delineation. If you do you're
essentially asking people to embed their competitor's component into
their broker so that their users can more easily migrate over to the
competition.
As you well know much of what Qpid is today falls into the competition
category, and this presents a very real problem for an effort like
Proton.
--Rafael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by Rob Godfrey <ro...@gmail.com>.
I'm about to head out on vacation for 10 days or so, and haven't had a
chance to read Rafi's document yet, but for the avoidance of doubt I'd
just like to make clear that I completely concur with the position
Gordon outlined below.
> In my mind, the purpose of Qpid has always been to develop software under
> the ASF governance and licensing in order to support adoption of AMQP and
> the emergence of an ecosystem built around it that better serves users
> needs.
Proton is a (big) part of that effort in my mind, and I think our
ability to contribute to the success of AMQP 1.0 would be (stupidly,
unnecessarily) harmed by diluting our efforts into different
"projects".
-- Rob
On 18 July 2012 20:05, Gordon Sim <gs...@redhat.com> wrote:
> On 07/18/2012 05:40 PM, Rafael Schloming wrote:
>>
>> So while the Proton mission is in many ways compatible with the
>> original Qpid charter, the de facto Qpid mission of today is really
>> quite different from Proton's.
>
>
> I tend to disagree.
>
> In my mind, the purpose of Qpid has always been to develop software under
> the ASF governance and licensing in order to support adoption of AMQP and
> the emergence of an ecosystem built around it that better serves users
> needs.
>
> At the time Qpid was formed, that meant client libraries and messaging
> brokers. We have always wanted to have embeddable libraries that other
> broker/clients/frameworks/etc could use to support AMQP however.
>
> As AMQP has evolved, a clearer, cleaner layering has emerged. The
> specification defines how different components can interoperate, rather than
> attempting to define the behaviour an interchangeable message broker (which
> the earlier specifications did not in fact achieve anyway).
>
> In addition I think through developing and maintaining different language
> implementations we have come to appreciate ways in which this can be kept
> more manageable for maintainers and less confusing for end users.
>
> The landscape is therefore different now than it was when Qpid began. To my
> mind however the mission of the project is not, though we should always be
> prepared as a community to re-evaluate how best to achieve it.
>
> I believe wholeheartedly in the development of a protocol engine for the
> three 'platforms' mentioned (C, Java and JavaScript). I believe these should
> be usable by any higher level component that wants to speak AMQP in some
> way, whether part of Qpid or not.
>
> It seems clear there is also opportunity for wide reuse of a 'driver' - an
> IO subsystem as you put it - designed to work well with the engine, for
> cases where that functionality is not already provided.
>
> I also fully appreciate and welcome the expanded understanding of the 'API
> space' that these developments have brought into focus, though I think there
> is still some thinking to be done there.
>
> As I stated on another thread, I think we need a shift in emphasis. A
> renewed emphasis on interoperability, a new emphasis on enabling an
> ecosystem that is wider than perhaps first imagined.
>
> To my mind this is not a change to the mission or Qpid, nor does not
> necessarily negate the value of existing components (though again, we should
> never be afraid to re-evaluate).
>
> An ASF governed, open, AMQP enabled JMS client is clearly a valuable piece
> of the 1.0 ecosystem, as is a broker that can support the full functionality
> that JMS defines. These should likewise be usable on their own, against
> AMQP-enabled components developed outside Qpid, and outside the ASF. They
> play a different role than proton in promoting AMQP, but in my view are
> merely different initiatives supporting the same mission.
>
> I anticipate new behaviours and components that can be built on top of the
> core AMQP protocol in the future and what better place to explore and
> develop those than here at Qpid, under an established, well respected
> governance model? I think we also have a responsibility, and perhaps a
> unique position, to help bridge users of the earlier revisions of AMQP onto
> the better world that 1.0 promises, the users that in large part have
> fuelled that very evolution of the specification.
>
> What structuring makes most sense is something I think will become clearer
> organically as we make progress. The key is - as always! - continual, open
> communication and debate, not only amongst the developers but with users in
> the widest sense.
>
> There is much to do! Let's get on and do it, remembering all the while to
> talk about what we are doing and be open and welcoming to all who wish to
> collaborate.
>
> --Gordon.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Thu, Jul 19, 2012 at 1:17 PM, Gordon Sim <gs...@redhat.com> wrote:
> So the idea would be to have an AMQP plugin that used proton as part of
> Apollo?
>
>
Yep, that's why I'm so interested in proton. I'd rather the QPID project
maintain a plugin like that, but if your not interested I'm willing to do
in it in ActiveMQ.
>
>> Naturally if something like this was to occur, the Qpid broker devs would
>> quickly get commit rights to ActiveMQ since they will probably need
>> to stretch and pull Apollo's broker core in new directions.
>>
>
> Yes, my one concern would be that we could offer 'full' AMQP support,
> including any extensions such as filters, or transaction coordination
> protocols, management mechanisms that may be defined in ongoing standards
> work.
Yep. Apollo would be happy to pulled in those directions :)
--
**
*Hiram Chirino*
*Software Fellow | FuseSource Corp.*
*chirino@fusesource.com | fusesource.com*
*skype: hiramchirino | twitter: @hiramchirino<http://twitter.com/hiramchirino>
*
*blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*
*
*
*
*
Re: proton: motivation and strategy
Posted by Gordon Sim <gs...@redhat.com>.
On 07/19/2012 04:59 PM, Hiram Chirino wrote:
> Well, from a ASF point of view there is some duplication of effort in
> maintaing a Qpid Java broker and a ActiveMQ java broker. They both target
> similar users (folks who like running apps on the JVM) and use cases. This
> situation will be even more intese once ActiveMQ implements the AMQP 1.0
> spec.
Agreed.
> From my point of view, and it's a VERY biased and insensitive point of view
> (sorry if I offend anyone):
Your point of view is very far from being insensitive so please don't be
concerned at giving any offence! I asked for your opinion, and am
grateful for it.
> <dream>
> The ideal split of *Java* tech bits across the projects would be to have
> QPID implement all the non-broker specific libs like Proton, clients,
> bridges and perhaps even proxies/intermediaries. (Here's where the very
> biased bit comes in...) Then QPID folks then implement/maintain an AMQP
> java broker on using ActiveMQ's Apollo project and Qpid's non-broker
> specific bits.
>
> In Apollo the protocols are implemented a plugins on top of the core. You
> could take the Apollo distro, strip out the STOMP protocol it ships, and
> then slap on your AMQP implementation. So you could end up with a broker
> which focused on just AMQP hopefully keeping your current QPID java broker
> users happy.
So the idea would be to have an AMQP plugin that used proton as part of
Apollo?
> The current plan is for Apollo to eventually become AcitveMQ 6. ActiveMQ 6
> could then continue to be the ASF's multi-protocol Java messaging broker.
> It would repackage Apollo + QPID's Apollo AMQP impl + Apollo's STOMP impl
> + ActiveMQ's current protocol impl + other bits like an MQTT protocol impl.
> That means Qpid's AMQP broker impl would also tag along and make it
> upstream into lots of other projects like ServiceMix and Apache Geronimo.
To me, at least at this high level view, that would seem to make a lot
of sense and I suspect would make a lot of users happy.
> The nice thing all the projects would have a nice common broker base we
> could collaborate on (the Apollo core). Each project could release broker
> distos which are focused on 1 protocol, and the ActiveMQ distro could
> repackage everything into one monstrous distribution where all the
> protocols are integrated.
>
> Naturally if something like this was to occur, the Qpid broker devs would
> quickly get commit rights to ActiveMQ since they will probably need
> to stretch and pull Apollo's broker core in new directions.
Yes, my one concern would be that we could offer 'full' AMQP support,
including any extensions such as filters, or transaction coordination
protocols, management mechanisms that may be defined in ongoing
standards work.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Thu, Jul 19, 2012 at 11:14 AM, Gordon Sim <gs...@redhat.com> wrote:
> On 07/19/2012 03:48 PM, Hiram Chirino wrote:
>
>> I'm interested in using Proton in the ActiveMQ's Apollo message broker.
>>
>
> Great!
>
> I don't know how closely you are following this thread, but
I've been following it since the Proton bits interest me very much.
> what would your view be of the feasibility of evolving to a single AMQP
> based broker at Apache? We have two brokers already at Qpid and are very
> concious of duplicated effort.
I don't think I'm qualified to comment on the pros and cons of your the vs
C++ based AMQP broker. So I'm not sure if those 2 could be consolidated in
some way.
> The nature of AMQP 1.0 makes it less restrictive in terms of broker
> 'model'.
>
A very good thing.
> I certainly don't have anything like a concrete proposal. I'm just
> thinking aloud, noting that combining efforts if possible would be ideal,
> and wondering how far that view may be shared.
Well, from a ASF point of view there is some duplication of effort in
maintaing a Qpid Java broker and a ActiveMQ java broker. They both target
similar users (folks who like running apps on the JVM) and use cases. This
situation will be even more intese once ActiveMQ implements the AMQP 1.0
spec.
>From my point of view, and it's a VERY biased and insensitive point of view
(sorry if I offend anyone):
<dream>
The ideal split of *Java* tech bits across the projects would be to have
QPID implement all the non-broker specific libs like Proton, clients,
bridges and perhaps even proxies/intermediaries. (Here's where the very
biased bit comes in...) Then QPID folks then implement/maintain an AMQP
java broker on using ActiveMQ's Apollo project and Qpid's non-broker
specific bits.
In Apollo the protocols are implemented a plugins on top of the core. You
could take the Apollo distro, strip out the STOMP protocol it ships, and
then slap on your AMQP implementation. So you could end up with a broker
which focused on just AMQP hopefully keeping your current QPID java broker
users happy.
The current plan is for Apollo to eventually become AcitveMQ 6. ActiveMQ 6
could then continue to be the ASF's multi-protocol Java messaging broker.
It would repackage Apollo + QPID's Apollo AMQP impl + Apollo's STOMP impl
+ ActiveMQ's current protocol impl + other bits like an MQTT protocol impl.
That means Qpid's AMQP broker impl would also tag along and make it
upstream into lots of other projects like ServiceMix and Apache Geronimo.
The nice thing all the projects would have a nice common broker base we
could collaborate on (the Apollo core). Each project could release broker
distos which are focused on 1 protocol, and the ActiveMQ distro could
repackage everything into one monstrous distribution where all the
protocols are integrated.
Naturally if something like this was to occur, the Qpid broker devs would
quickly get commit rights to ActiveMQ since they will probably need
to stretch and pull Apollo's broker core in new directions.
</dream>
--
**
*Hiram Chirino*
*Software Fellow | FuseSource Corp.*
*chirino@fusesource.com | fusesource.com*
*skype: hiramchirino | twitter: @hiramchirino<http://twitter.com/hiramchirino>
*
*blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*
*
*
*
*
Re: proton: motivation and strategy
Posted by Gordon Sim <gs...@redhat.com>.
On 07/19/2012 03:48 PM, Hiram Chirino wrote:
> I'm interested in using Proton in the ActiveMQ's Apollo message broker.
Great!
I don't know how closely you are following this thread, but what would
your view be of the feasibility of evolving to a single AMQP based
broker at Apache? We have two brokers already at Qpid and are very
concious of duplicated effort. The nature of AMQP 1.0 makes it less
restrictive in terms of broker 'model'.
I certainly don't have anything like a concrete proposal. I'm just
thinking aloud, noting that combining efforts if possible would be
ideal, and wondering how far that view may be shared.
> From my point of view, I'd be happy if Proton stays in Qpid as long it
> continues to make progress so that It can be used by Apollo.
Excellent!
> Progress not
> only features and stability be also in terms of timely releases. If for
> whatever reason the QPID pmc fails to foster that progress, I'm sure the
> ActiveMQ pmc would be happy help those team members working on Proton in
> any way it can.
Personally I don't see there being any issue here. I have seen no
opposition to proton, indeed I think there has been a great deal of
support expressed. A separate svn tree has been created and I think
there is broad support for a separate JIRA instance and indeed a
separate mailing list. I myself don't see that latter as necessary, but
have in no way opposed it. There has been some discussion on different
preferences for the name of the list (reflecting subtly different view
of its intended focus). Nothing that I think could reasonably be seen as
hampering progress yet. (just my 2 cents though)/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Hi Folks,
I'm interested in using Proton in the ActiveMQ's Apollo message broker.
From my point of view, I'd be happy if Proton stays in Qpid as long it
continues to make progress so that It can be used by Apollo. Progress not
only features and stability be also in terms of timely releases. If for
whatever reason the QPID pmc fails to foster that progress, I'm sure the
ActiveMQ pmc would be happy help those team members working on Proton in
any way it can.
Regards,
Hiram
On Thu, Jul 19, 2012 at 9:43 AM, Rajith Attapattu <ra...@gmail.com>wrote:
> On Thu, Jul 19, 2012 at 8:26 AM, Gordon Sim <gs...@redhat.com> wrote:
> > To me the key is that they be governed in 'The Apache Way' - openly,
> > meritocratically, seeking consensus - as the best way to serve the
> community
> > as a whole.
> >
> > As I said, I think the actual structure that makes the most sense will I
> > think become clearer with time. I can see merit in all three of the
> > hypothetical scenarios you listed.
> >
> > Lets get through a couple of proton releases; lets grow the community and
> > hear how they get on using it; lets see where the deeper understanding of
> > APIs that has emerged leads us; and yes, by all means lets re-evaluate
> what
> > we are doing along side proton.
>
> This is precisely my point too. Let it grow organically and time will
> tell what the correct approach should be.
>
> However lets not get into silly arguments about a mailing list.
> ** A separate mailing list doesn't imply we are deciding on a
> particular approach. **
> There seems to be an audience out there that is interested in
> "Proton", but not necessarily Qpid.
> So lets help them get on board with a separate mailing list. Lets not
> make silly arguments like adding mail filters etc...
>
> An extra mailing list is not going to cost us anything. If this proves
> to be low traffic we can easily get rid of it in the future !
>
> Rajith
>
> P.S Gordon I didn't imply you are the one making the silly argument.
> Rather I used your point about growing the community and deciding
> later, as a basis for addressing the community in general.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
--
**
*Hiram Chirino*
*Software Fellow | FuseSource Corp.*
*chirino@fusesource.com | fusesource.com*
*skype: hiramchirino | twitter: @hiramchirino<http://twitter.com/hiramchirino>
*
*blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*
*
*
*
*
Re: proton: motivation and strategy
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, Jul 19, 2012 at 8:26 AM, Gordon Sim <gs...@redhat.com> wrote:
> To me the key is that they be governed in 'The Apache Way' - openly,
> meritocratically, seeking consensus - as the best way to serve the community
> as a whole.
>
> As I said, I think the actual structure that makes the most sense will I
> think become clearer with time. I can see merit in all three of the
> hypothetical scenarios you listed.
>
> Lets get through a couple of proton releases; lets grow the community and
> hear how they get on using it; lets see where the deeper understanding of
> APIs that has emerged leads us; and yes, by all means lets re-evaluate what
> we are doing along side proton.
This is precisely my point too. Let it grow organically and time will
tell what the correct approach should be.
However lets not get into silly arguments about a mailing list.
** A separate mailing list doesn't imply we are deciding on a
particular approach. **
There seems to be an audience out there that is interested in
"Proton", but not necessarily Qpid.
So lets help them get on board with a separate mailing list. Lets not
make silly arguments like adding mail filters etc...
An extra mailing list is not going to cost us anything. If this proves
to be low traffic we can easily get rid of it in the future !
Rajith
P.S Gordon I didn't imply you are the one making the silly argument.
Rather I used your point about growing the community and deciding
later, as a basis for addressing the community in general.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by Gordon Sim <gs...@redhat.com>.
On 07/19/2012 01:13 AM, Rafael Schloming wrote:
> On Wed, 2012-07-18 at 19:05 +0100, Gordon Sim wrote:
>> On 07/18/2012 05:40 PM, Rafael Schloming wrote:
>>> So while the Proton mission is in many ways compatible with the
>>> original Qpid charter, the de facto Qpid mission of today is really
>>> quite different from Proton's.
>>
>> I tend to disagree.
I should have pointed out that while I have a different, though I think
not entirely opposing, view to you on this one aspect, I agree entirely
with the bulk of what your wrote.
>>
>> In my mind, the purpose of Qpid has always been to develop software
>> under the ASF governance and licensing in order to support adoption of
>> AMQP and the emergence of an ecosystem built around it that better
>> serves users needs.
>
> As I stated above, I agree that the Proton mission is compatible with
> the original Qpid charter, but I believe they are still quite different.
> The above statement permits the development of just about any kind of
> application that happens to speak AMQP since that furthers adoption of
> AMQP.
Yes, I think in my view that is indeed the case.
> The Proton mission on the other hand is about making it as easy as
> possible for any application (either existing or under development) to
> speak AMQP. This really doesn't include building any such applications
> as part of Proton, and doing so would compromise Proton's embeddability
> and neutrality.
To my mind, that is merely stating that Proton plays a specific, well
defined role in achieving the Qpid mission. The same is true for e.g. a
JMS client. Qpid's mission as a whole encompasses the different strands.
>> At the time Qpid was formed, that meant client libraries and messaging
>> brokers. We have always wanted to have embeddable libraries that other
>> broker/clients/frameworks/etc could use to support AMQP however.
>>
>> As AMQP has evolved, a clearer, cleaner layering has emerged. The
>> specification defines how different components can interoperate, rather
>> than attempting to define the behaviour an interchangeable message
>> broker (which the earlier specifications did not in fact achieve anyway).
>>
>> In addition I think through developing and maintaining different
>> language implementations we have come to appreciate ways in which this
>> can be kept more manageable for maintainers and less confusing for end
>> users.
>>
>> The landscape is therefore different now than it was when Qpid began. To
>> my mind however the mission of the project is not, though we should
>> always be prepared as a community to re-evaluate how best to achieve it.
>
> I think the problem is that were we to reform Qpid in today's world, the
> best way to support adoption of AMQP would not be to build yet another
> broker, but rather to build a library that makes it easy to adapt all of
> the many existing brokers to speak AMQP. That is certainly very much
> where proton is aimed, but unless you're prepared to take the view that
> we should dump the brokers and ignore existing Qpid users, it's a
> stretch to say that the de facto mission is no different from the
> original as the de facto mission clearly involves doing something with
> the brokers we've built.
I don't think ignoring users is ever something we should do.
However I think we should always be fully prepared to re-evaluate how we
are achieving and re-prioritise if needed. As such questioning whether
the brokers or indeed any component are failing to adequately meet our
overall objective and if so to take appropriate action is entirely
sensible. What we have today need not constrain what we have in the future.
I do think that in the 1.0 landscape a message broker is going to be a
very, very common part of the deployed infrastructure. I absolutely
agree that we should be providing a library that makes it easy for any
existing broker to support AMQP. However I also think it is important to
have a truly open, ASF governed AMQP broker. I don't see these separate
strands as in any way in conflict.
>> I believe wholeheartedly in the development of a protocol engine for the
>> three 'platforms' mentioned (C, Java and JavaScript). I believe these
>> should be usable by any higher level component that wants to speak AMQP
>> in some way, whether part of Qpid or not.
>>
>> It seems clear there is also opportunity for wide reuse of a 'driver' -
>> an IO subsystem as you put it - designed to work well with the engine,
>> for cases where that functionality is not already provided.
>>
>> I also fully appreciate and welcome the expanded understanding of the
>> 'API space' that these developments have brought into focus, though I
>> think there is still some thinking to be done there.
>>
>> As I stated on another thread, I think we need a shift in emphasis. A
>> renewed emphasis on interoperability, a new emphasis on enabling an
>> ecosystem that is wider than perhaps first imagined.
>>
>> To my mind this is not a change to the mission or Qpid, nor does not
>> necessarily negate the value of existing components (though again, we
>> should never be afraid to re-evaluate).
>
> To be clear, I don't believe I ever proposed any sort of change to the
> Qpid mission.
Indeed not, and I was certainly not implying that you did. I simply
meant that the 'defacto Qpid mission of today' is in my view the same as
it was at the projects inception. The changing landscape in which we
evaluate that mission, or any loss of focus on it that may have occurred
and need corrected, is a separate thing.
> My point is that the Proton mission is just different to
> the Qpid mission *of today* (if it were not there would be no point in
> doing it),
I don't follow your logic there. I would say that the purpose of Proton
follows quite logically from the mission of Qpid, as your excellent
notes pointed out so clearly.
> and depending on what you think the Qpid mission is or should
> be, you may feel it is more or less compatible and/or overlapping with
> the Proton mission. For example, lot's of people think that Qpid is
> about building brokers, and that's pretty much entirely disjoint to what
> Proton is about.
I'm firmly in the camp that is 100% comfortable with Proton being
entirely compatible with-, and supportive of-, the Qpid mission.
However equally I have no philosophical objection to spinning of proton
or indeed any other component(s) as a separate top level project in the
future. (Apache Hadoop is perhaps a good example).
>> An ASF governed, open, AMQP enabled JMS client is clearly a valuable
>> piece of the 1.0 ecosystem, as is a broker that can support the full
>> functionality that JMS defines. These should likewise be usable on their
>> own, against AMQP-enabled components developed outside Qpid, and outside
>> the ASF. They play a different role than proton in promoting AMQP, but
>> in my view are merely different initiatives supporting the same mission.
>
> What's the important distinction between initiative and mission? I
> certainly think you can interpret the Qpid mission as broad enough to
> include a lot of things, but that simply begs the question of what are
> the sub-missions/objectives/whatever of each initiative, and how are
> they governed when they have distinct sets of users?
I agree, any task or artefact can generally be broken down into smaller
components.
(Indeed, if you'll forgive the digression, the very name of Proton
provides an interesting analogy there. The atom is no longer seen as
indivisible; the proton is itself composed of quarks).
To me the key is that they be governed in 'The Apache Way' - openly,
meritocratically, seeking consensus - as the best way to serve the
community as a whole.
As I said, I think the actual structure that makes the most sense will I
think become clearer with time. I can see merit in all three of the
hypothetical scenarios you listed.
Lets get through a couple of proton releases; lets grow the community
and hear how they get on using it; lets see where the deeper
understanding of APIs that has emerged leads us; and yes, by all means
lets re-evaluate what we are doing along side proton.
>> I anticipate new behaviours and components that can be built on top of
>> the core AMQP protocol in the future and what better place to explore
>> and develop those than here at Qpid, under an established, well
>> respected governance model? I think we also have a responsibility, and
>> perhaps a unique position, to help bridge users of the earlier revisions
>> of AMQP onto the better world that 1.0 promises, the users that in large
>> part have fuelled that very evolution of the specification.
>
> How do you define what is in/out? If I write a chat server, distributed
> ray tracer, or MMO that happens to speak AMQP, is Qpid the perfect place
> to build these things?
I think to me an important question is what the primary purpose of the
hypothetical component is. The primary purpose of an AMQP broker is to
be an intermediary in AMQP-based communication and that I think is
within the scope of the mission. The primary purpose of a ray tracer
seems on the face of it to be out of scope to me.
However, such decisions should always be based on debates in the
community. We don't want one-man projects, we want community initiatives
and the community can thrash out the best structure.
>> What structuring makes most sense is something I think will become
>> clearer organically as we make progress. The key is - as always! -
>> continual, open communication and debate, not only amongst the
>> developers but with users in the widest sense.
>
> I think it's important to recognize that Proton needs to be *neutral*,
> i.e. it is a general purpose library that any application can use to
> speak AMQP.
Agree 100%.
> It can't favor any one particular application's usage of
> AMQP, for example Bundling together a JMS Broker with Proton would
> obviously give any existing JMS vendor pause if they were considering
> using Proton to support AMQP.
I don't think anyone is proposing bundling a JMS broker with the
library. I believe the intention is to have them as completely separate
artefacts. The svn structure was explicitly designed to make that clear.
The fact that a broker might be available from the same source is an
entirely separate thing. I don't see why a vendor who found one
component useful would be hindered from using that simply because they
offered an alternative to some other component.
As you point out, proton has evolved towards providing a general purpose
API. Now a broker vendor may well have their own APIs and clients, and
could in some sense be seen to be offering an alternative even to
proton. They are free to pick and choose the pieces they find is useful,
and indeed to get involved in shaping those pieces.
> So while it's all fine and well to paint a picture of Qpid as an
> umbrella project which is open to all things AMQP, that picture is
> missing an important distinction between software that underpins an
> ecosystem (e.g. the TCP stack), and software that is part of an
> ecosystem (e.g. an http server).
Yes, that is a good distinction. To me though it simply distinguishes
different roles. It doesn't in and of itself mean that different layers
in the stack can't be used and developed in the same community, even if
some users choose different sub-sets of that stack.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by Rafael Schloming <ra...@redhat.com>.
On Wed, 2012-07-18 at 20:37 -0400, Carl Trieloff wrote:
> > I think the problem is that were we to reform Qpid in today's world, the
> > best way to support adoption of AMQP would not be to build yet another
> > broker, but rather to build a library that makes it easy to adapt all of
> > the many existing brokers to speak AMQP. That is certainly very much
> > where proton is aimed, but unless you're prepared to take the view that
> > we should dump the brokers and ignore existing Qpid users, it's a
> > stretch to say that the de facto mission is no different from the
> > original as the de facto mission clearly involves doing something with
> > the brokers we've built.
>
>
> I disagree, many project have not tackled the issues many messaging
> projects have, and thus it is valuable to have a broker that serves the
> user and also pushes on some of the technological boundries.
>
> Qpid in many cases has introduced many other project to such capabilities.
The value of adding another Broker into the mix is certainly debatable,
but that's an orthogonal issue. Even if I were to agree with you that
there is value to bulding a fantastic new broker from the ground up to
support AMQP 1.0, this would not make sense to mix together into the
same project/sub-project with Proton as this new broker is competing
with all the existing brokers out there, and Proton is trying to
cooperate with them in order to spread AMQP.
> > To be clear, I don't believe I ever proposed any sort of change to the
> > Qpid mission. My point is that the Proton mission is just different to
> > the Qpid mission *of today* (if it were not there would be no point in
> > doing it), and depending on what you think the Qpid mission is or should
> > be, you may feel it is more or less compatible and/or overlapping with
> > the Proton mission. For example, lot's of people think that Qpid is
> > about building brokers, and that's pretty much entirely disjoint to what
> > Proton is about.
>
>
> Building a broker is part of the qpid mission, but providing protocol
> libs, clients libs etc are also.
>
> technically we could structure the protocol work (proton), client libs,
> qmf etc into sub-projects....
The Proton mission isn't just about providing protocol libs, it's about
actually getting as many existing apps out there to use them as
possible, and mixing those libraries together with competing apps is
counter to that goal.
Put another way, the mission of competing with other message brokers
with an implementation that happens to use AMQP is not compatible with
the mission of cooperating with them in an effort to spread AMQP. While
these two things could coexist as separate sub projects within an
umbrella project, the overall mission of that umbrella project and the
governance of the sub projects within the umbrella really needs to be at
least a little more explicitly defined and communicated than say e.g. a
single project that happens to release multiple artifacts.
--Rafael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by Carl Trieloff <cc...@redhat.com>.
On 07/18/2012 08:13 PM, Rafael Schloming wrote:
> On Wed, 2012-07-18 at 19:05 +0100, Gordon Sim wrote:
>> On 07/18/2012 05:40 PM, Rafael Schloming wrote:
>>> So while the Proton mission is in many ways compatible with the
>>> original Qpid charter, the de facto Qpid mission of today is really
>>> quite different from Proton's.
>> I tend to disagree.
>>
>> In my mind, the purpose of Qpid has always been to develop software
>> under the ASF governance and licensing in order to support adoption of
>> AMQP and the emergence of an ecosystem built around it that better
>> serves users needs.
> As I stated above, I agree that the Proton mission is compatible with
> the original Qpid charter, but I believe they are still quite different.
> The above statement permits the development of just about any kind of
> application that happens to speak AMQP since that furthers adoption of
> AMQP.
>
> The Proton mission on the other hand is about making it as easy as
> possible for any application (either existing or under development) to
> speak AMQP. This really doesn't include building any such applications
> as part of Proton, and doing so would compromise Proton's embeddability
> and neutrality.
That seems like I fine goal to be a sub-project of qpid
>
>> At the time Qpid was formed, that meant client libraries and messaging
>> brokers. We have always wanted to have embeddable libraries that other
>> broker/clients/frameworks/etc could use to support AMQP however.
>>
>> As AMQP has evolved, a clearer, cleaner layering has emerged. The
>> specification defines how different components can interoperate, rather
>> than attempting to define the behaviour an interchangeable message
>> broker (which the earlier specifications did not in fact achieve anyway).
>>
>> In addition I think through developing and maintaining different
>> language implementations we have come to appreciate ways in which this
>> can be kept more manageable for maintainers and less confusing for end
>> users.
>>
>> The landscape is therefore different now than it was when Qpid began. To
>> my mind however the mission of the project is not, though we should
>> always be prepared as a community to re-evaluate how best to achieve it.
> I think the problem is that were we to reform Qpid in today's world, the
> best way to support adoption of AMQP would not be to build yet another
> broker, but rather to build a library that makes it easy to adapt all of
> the many existing brokers to speak AMQP. That is certainly very much
> where proton is aimed, but unless you're prepared to take the view that
> we should dump the brokers and ignore existing Qpid users, it's a
> stretch to say that the de facto mission is no different from the
> original as the de facto mission clearly involves doing something with
> the brokers we've built.
I disagree, many project have not tackled the issues many messaging
projects have, and thus it is valuable to have a broker that serves the
user and also pushes on some of the technological boundries.
Qpid in many cases has introduced many other project to such capabilities.
>
>> I believe wholeheartedly in the development of a protocol engine for the
>> three 'platforms' mentioned (C, Java and JavaScript). I believe these
>> should be usable by any higher level component that wants to speak AMQP
>> in some way, whether part of Qpid or not.
>>
>> It seems clear there is also opportunity for wide reuse of a 'driver' -
>> an IO subsystem as you put it - designed to work well with the engine,
>> for cases where that functionality is not already provided.
>>
>> I also fully appreciate and welcome the expanded understanding of the
>> 'API space' that these developments have brought into focus, though I
>> think there is still some thinking to be done there.
>>
>> As I stated on another thread, I think we need a shift in emphasis. A
>> renewed emphasis on interoperability, a new emphasis on enabling an
>> ecosystem that is wider than perhaps first imagined.
>>
>> To my mind this is not a change to the mission or Qpid, nor does not
>> necessarily negate the value of existing components (though again, we
>> should never be afraid to re-evaluate).
> To be clear, I don't believe I ever proposed any sort of change to the
> Qpid mission. My point is that the Proton mission is just different to
> the Qpid mission *of today* (if it were not there would be no point in
> doing it), and depending on what you think the Qpid mission is or should
> be, you may feel it is more or less compatible and/or overlapping with
> the Proton mission. For example, lot's of people think that Qpid is
> about building brokers, and that's pretty much entirely disjoint to what
> Proton is about.
Building a broker is part of the qpid mission, but providing protocol
libs, clients libs etc are also.
technically we could structure the protocol work (proton), client libs,
qmf etc into sub-projects....
>> An ASF governed, open, AMQP enabled JMS client is clearly a valuable
>> piece of the 1.0 ecosystem, as is a broker that can support the full
>> functionality that JMS defines. These should likewise be usable on their
>> own, against AMQP-enabled components developed outside Qpid, and outside
>> the ASF. They play a different role than proton in promoting AMQP, but
>> in my view are merely different initiatives supporting the same mission.
> What's the important distinction between initiative and mission? I
> certainly think you can interpret the Qpid mission as broad enough to
> include a lot of things, but that simply begs the question of what are
> the sub-missions/objectives/whatever of each initiative, and how are
> they governed when they have distinct sets of users?
>
they are all governed by the TLP Qpid. they can each have there own
goals, etc and once they have a user base it becomes appropriate to
create lists etc once the traffic get to that point... I believe that
was the reasoning we used when qmf was debated in this light.
Carl.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by Rafael Schloming <ra...@redhat.com>.
On Wed, 2012-07-18 at 19:05 +0100, Gordon Sim wrote:
> On 07/18/2012 05:40 PM, Rafael Schloming wrote:
> > So while the Proton mission is in many ways compatible with the
> > original Qpid charter, the de facto Qpid mission of today is really
> > quite different from Proton's.
>
> I tend to disagree.
>
> In my mind, the purpose of Qpid has always been to develop software
> under the ASF governance and licensing in order to support adoption of
> AMQP and the emergence of an ecosystem built around it that better
> serves users needs.
As I stated above, I agree that the Proton mission is compatible with
the original Qpid charter, but I believe they are still quite different.
The above statement permits the development of just about any kind of
application that happens to speak AMQP since that furthers adoption of
AMQP.
The Proton mission on the other hand is about making it as easy as
possible for any application (either existing or under development) to
speak AMQP. This really doesn't include building any such applications
as part of Proton, and doing so would compromise Proton's embeddability
and neutrality.
> At the time Qpid was formed, that meant client libraries and messaging
> brokers. We have always wanted to have embeddable libraries that other
> broker/clients/frameworks/etc could use to support AMQP however.
>
> As AMQP has evolved, a clearer, cleaner layering has emerged. The
> specification defines how different components can interoperate, rather
> than attempting to define the behaviour an interchangeable message
> broker (which the earlier specifications did not in fact achieve anyway).
>
> In addition I think through developing and maintaining different
> language implementations we have come to appreciate ways in which this
> can be kept more manageable for maintainers and less confusing for end
> users.
>
> The landscape is therefore different now than it was when Qpid began. To
> my mind however the mission of the project is not, though we should
> always be prepared as a community to re-evaluate how best to achieve it.
I think the problem is that were we to reform Qpid in today's world, the
best way to support adoption of AMQP would not be to build yet another
broker, but rather to build a library that makes it easy to adapt all of
the many existing brokers to speak AMQP. That is certainly very much
where proton is aimed, but unless you're prepared to take the view that
we should dump the brokers and ignore existing Qpid users, it's a
stretch to say that the de facto mission is no different from the
original as the de facto mission clearly involves doing something with
the brokers we've built.
> I believe wholeheartedly in the development of a protocol engine for the
> three 'platforms' mentioned (C, Java and JavaScript). I believe these
> should be usable by any higher level component that wants to speak AMQP
> in some way, whether part of Qpid or not.
>
> It seems clear there is also opportunity for wide reuse of a 'driver' -
> an IO subsystem as you put it - designed to work well with the engine,
> for cases where that functionality is not already provided.
>
> I also fully appreciate and welcome the expanded understanding of the
> 'API space' that these developments have brought into focus, though I
> think there is still some thinking to be done there.
>
> As I stated on another thread, I think we need a shift in emphasis. A
> renewed emphasis on interoperability, a new emphasis on enabling an
> ecosystem that is wider than perhaps first imagined.
>
> To my mind this is not a change to the mission or Qpid, nor does not
> necessarily negate the value of existing components (though again, we
> should never be afraid to re-evaluate).
To be clear, I don't believe I ever proposed any sort of change to the
Qpid mission. My point is that the Proton mission is just different to
the Qpid mission *of today* (if it were not there would be no point in
doing it), and depending on what you think the Qpid mission is or should
be, you may feel it is more or less compatible and/or overlapping with
the Proton mission. For example, lot's of people think that Qpid is
about building brokers, and that's pretty much entirely disjoint to what
Proton is about.
> An ASF governed, open, AMQP enabled JMS client is clearly a valuable
> piece of the 1.0 ecosystem, as is a broker that can support the full
> functionality that JMS defines. These should likewise be usable on their
> own, against AMQP-enabled components developed outside Qpid, and outside
> the ASF. They play a different role than proton in promoting AMQP, but
> in my view are merely different initiatives supporting the same mission.
What's the important distinction between initiative and mission? I
certainly think you can interpret the Qpid mission as broad enough to
include a lot of things, but that simply begs the question of what are
the sub-missions/objectives/whatever of each initiative, and how are
they governed when they have distinct sets of users?
> I anticipate new behaviours and components that can be built on top of
> the core AMQP protocol in the future and what better place to explore
> and develop those than here at Qpid, under an established, well
> respected governance model? I think we also have a responsibility, and
> perhaps a unique position, to help bridge users of the earlier revisions
> of AMQP onto the better world that 1.0 promises, the users that in large
> part have fuelled that very evolution of the specification.
How do you define what is in/out? If I write a chat server, distributed
ray tracer, or MMO that happens to speak AMQP, is Qpid the perfect place
to build these things?
> What structuring makes most sense is something I think will become
> clearer organically as we make progress. The key is - as always! -
> continual, open communication and debate, not only amongst the
> developers but with users in the widest sense.
I think it's important to recognize that Proton needs to be *neutral*,
i.e. it is a general purpose library that any application can use to
speak AMQP. It can't favor any one particular application's usage of
AMQP, for example Bundling together a JMS Broker with Proton would
obviously give any existing JMS vendor pause if they were considering
using Proton to support AMQP.
So while it's all fine and well to paint a picture of Qpid as an
umbrella project which is open to all things AMQP, that picture is
missing an important distinction between software that underpins an
ecosystem (e.g. the TCP stack), and software that is part of an
ecosystem (e.g. an http server).
--Rafael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: proton: motivation and strategy
Posted by Gordon Sim <gs...@redhat.com>.
On 07/18/2012 05:40 PM, Rafael Schloming wrote:
> So while the Proton mission is in many ways compatible with the
> original Qpid charter, the de facto Qpid mission of today is really
> quite different from Proton's.
I tend to disagree.
In my mind, the purpose of Qpid has always been to develop software
under the ASF governance and licensing in order to support adoption of
AMQP and the emergence of an ecosystem built around it that better
serves users needs.
At the time Qpid was formed, that meant client libraries and messaging
brokers. We have always wanted to have embeddable libraries that other
broker/clients/frameworks/etc could use to support AMQP however.
As AMQP has evolved, a clearer, cleaner layering has emerged. The
specification defines how different components can interoperate, rather
than attempting to define the behaviour an interchangeable message
broker (which the earlier specifications did not in fact achieve anyway).
In addition I think through developing and maintaining different
language implementations we have come to appreciate ways in which this
can be kept more manageable for maintainers and less confusing for end
users.
The landscape is therefore different now than it was when Qpid began. To
my mind however the mission of the project is not, though we should
always be prepared as a community to re-evaluate how best to achieve it.
I believe wholeheartedly in the development of a protocol engine for the
three 'platforms' mentioned (C, Java and JavaScript). I believe these
should be usable by any higher level component that wants to speak AMQP
in some way, whether part of Qpid or not.
It seems clear there is also opportunity for wide reuse of a 'driver' -
an IO subsystem as you put it - designed to work well with the engine,
for cases where that functionality is not already provided.
I also fully appreciate and welcome the expanded understanding of the
'API space' that these developments have brought into focus, though I
think there is still some thinking to be done there.
As I stated on another thread, I think we need a shift in emphasis. A
renewed emphasis on interoperability, a new emphasis on enabling an
ecosystem that is wider than perhaps first imagined.
To my mind this is not a change to the mission or Qpid, nor does not
necessarily negate the value of existing components (though again, we
should never be afraid to re-evaluate).
An ASF governed, open, AMQP enabled JMS client is clearly a valuable
piece of the 1.0 ecosystem, as is a broker that can support the full
functionality that JMS defines. These should likewise be usable on their
own, against AMQP-enabled components developed outside Qpid, and outside
the ASF. They play a different role than proton in promoting AMQP, but
in my view are merely different initiatives supporting the same mission.
I anticipate new behaviours and components that can be built on top of
the core AMQP protocol in the future and what better place to explore
and develop those than here at Qpid, under an established, well
respected governance model? I think we also have a responsibility, and
perhaps a unique position, to help bridge users of the earlier revisions
of AMQP onto the better world that 1.0 promises, the users that in large
part have fuelled that very evolution of the specification.
What structuring makes most sense is something I think will become
clearer organically as we make progress. The key is - as always! -
continual, open communication and debate, not only amongst the
developers but with users in the widest sense.
There is much to do! Let's get on and do it, remembering all the while
to talk about what we are doing and be open and welcoming to all who
wish to collaborate.
--Gordon.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org