Re: Any ETA on a QPid 0.32 release
Based on what we've discussed so far, here's what I propose: We prepare one more cross-component Qpid release, 0.32. This time, the components share a version number and a source branch. Next time they won't. I'll manage the C++, Python, and related components. I will leave the Java component to Keith or whoever elects to take it on. After we branch for Beta, we'll start to reorganize the source tree for independent releases. For reasons of continuity, the next C++ and Python releases will use the version number "33", without the leading "0.". For 0.32, I'd like to try to stick with the schedule I posted earlier: end of this month for Alpha, and middle of February for Beta. Justin On Tue, Jan 27, 2015 at 5:46 AM, Rob Godfrey wrote: > I strongly agree with Keith that any change to the source tree should > happen (immediately) after (branching for) the next release. We can have > separate people managing the different components if we like, but I think > for this release we would be looking at a single release date and running > the existing release scripts. After this release we can work out exactly > how we want to release each component separately. > > In terms of numbering, I'm relatively relaxed as to whether we change now > or at the next release - I don't think the two changes have to be > coincident. > > As an aside, in terms of release numbering, somewhat coincidentally this > will be (if I have calculated this correctly) the 15th release of Qpid > since graduation (the first release was 0.5, then 0.6 and thereafter we > always incremented by 0.2), so calling this release 15.1 (as the first > release after an arbitrary rebasing of the version numbers) would be fine > by me :-) > > -- Rob > > On 23 January 2015 at 15:54, Keith W wrote: > >> Hi Justin >> >> I'm in agreement with the plan to reorganise the source tree in the way >> you >> describe (and expect that we would want a similar change for java) but am >> I >> concerned about the timing of such a big change.We should be >> reorganising trunk just *after* a release branch to give us plenty of time >> to work through the inevitable unexpected consequences properly. >> >> I am in favour of having one more qpid-wide release (and I would suggest >> we >> stick with our existing numbering scheme i.e. 0.32), then split the source >> tree and adopt the new numbering convention for the next -modular- >> releases. >> >> Thoughts? >> >> cheers, Keith. >> >> >> >> >> On 21 January 2015 at 12:35, Justin Ross wrote: >> >> > Hi, Keith. >> > >> > Apart from picking an approach for version numbers, I don't think there >> is >> > anything that should prevent you from starting an independent Java >> release. >> > >> > I've put some of my thoughts regarding source-tree organization down in >> > the wiki. Please feel free to add your own. >> > >> > >> > >> https://cwiki.apache.org/confluence/display/qpid/Source+tree+layout+proposal >> > >> > Whatever we decide on, we don't have to do it all at once in a big bang. >> > We can incrementally move modules into a new structure. >> > >> > Justin >> > >> > >> > On Fri, Jan 9, 2015 at 4:34 AM, Keith W wrote: >> > >> >> Hi all, >> >> >> >> Looking through this thread, it is not clear that we came to a settled >> >> position for release numbering, and when exactly we'd would move to >> >> releasing components independently. On the java side we are getting >> to a >> >> position where a release soon would be sensible. How best do we go >> >> forward? >> >> >> >> I'll be ready to put in some time helping plan/make the changes to the >> >> release system happen, once we agree what that direction should be. >> >> >> >> Kind regards, Keith. >> >> >> >> >> >> >> >> On 3 December 2014 at 15:15, Robbie Gemmell >> >> wrote: >> >> >> >> > In addition to [point] releases not actually occuring at the time the >> >> > version suggests, for me another downside of using the Year.Month >> >> > approach is that it doesnt as clearly convey a sense of impact for >> the >> >> > changes involved in the release, i.e is it a major or minor release, >> >> > are there any compatibility considerations etc. It might for a bugfix >> >> > release, e.g 15.1.1 vs 15.1, however should 16.1 be expected to be >> >> > majorly different than 15.12 or not, given it might have nearly 2 >> >> > months of changes in it, or possibly just days? If it isnt, >> >> > could/should it have been labeled 15.12.1 instead (at which point, >> >> > back to that naming vs timing issue)? Obviously we dont convey that >> >> > sort of information with the current versions, but it would be nice >> to >> >> > start. >> >> > >> >> > The major example of Year.Month naming that springs to mind for me is >> >> > Ubuntu, which isnt really quite the same situations since their >> >> > releases are mostly a distribution of other components, whicht are >> all >> >> > versioned independently and can often be updated to an extent between >> >> > the containing Year
RE: Proton Java Messenger API questions
Great - thanks very much for the quick reply and explanation! -Steve > -Original Message- > From: Rafael Schloming [mailto:r...@alum.mit.edu] > Sent: Monday, January 26, 2015 10:50 PM > To: users@qpid.apache.org > Subject: Re: Proton Java Messenger API questions > > On Mon, Jan 26, 2015 at 5:38 PM, Steve Huston > wrote: > > > Hi, > > I have a customer working on some development and trying the Proton > > Java Messenger API. They're having some problems and sent along the > > following questions. Could someone please help clarify these issues? > > Thanks, > > -Steve > > > > > > The roadmap is at a pretty high level. Any insight on what API > > stabilization means? > > > > Once Proton hits 1.0 I'd like to guarantee ABI stability (and API > compatibility) for the entire 1.x series. This is basically a bucket for > things to > fix prior to that point. Off the top of my head, things that fall into this > bucket > inculde: > > - removing deprecated/unused APIs (the driver, some of the more ancient > message codec routines) > - removing some useless duplicate structs > - making sure internal headers are not publicly accessible > - streamlining usage of the codec API > - streamlining sending/receiving messages > > > > Does API stabilization include some type of fatal error handling in > > the Messenger API? > > > > API stabilization is really about locking down the core APIs and making sure > we can commit to the ABI/API for long enough to justify a 1.x series. > Messenger's error handling doesn't really fall into this bucket. That's not to > say it won't happen, though. > > > > Going forward is the Messenger API going be the primary API or will > > most applications need to write directly to the lower levels (engine, > > transport...)? > > > > As it stands the Messenger API's lack of error handling (silent > > failure and continued operation under failure conditions) really makes > > the Messenger API unusable for real applications. > > > > Going forward, my plan is to reconcile Messenger with the Reactor API. I > believe by doing this we can provide a much better model for non blocking > use of messenger than the current API provides. I also intend to rework the > internals of messenger to operate as a set of cooperating handlers which can > be made accessible to applications, thereby allowing much more flexibility > and customization of a given messenger's behavior. The events framework > should also provide a strong basis for doing proper error handling, and the > timer system should make certain higher level features like automatic > reconnect possible. > > At its inception, Messenger's goal was to provide a very simple interface for > sending and receiving AMQP messages that doesn't require understanding > many more concepts than just "message" and "address". I still believe this is > a very important goal, however where the current Messenger API has fallen > short is in the ability to easily transition people to some of the more > advanced scenarios available to them with AMQP. I believe the above design > can address that shortcoming, so that is where I've been focusing my efforts. > > I know this doesn't directly answer your question of whether it will be "the > primary API", but my hope is to make that question kind of moot by making > transition between the messenger portion of the API and the rest of the API > smooth enough that you don't really need to choose up front which > approach to use. You can just do what is easiest for your initial use case > and if > you need to tweak something at a lower level or provide some aspect of > higher level functionality, that will be easy to do. > > Initially I'm doing all this on the C side only simply because it involves a > fair > amount of exploratory coding and design work and doing that in two > languages simultaneously is not very efficient at all. Once the design is in > place though, I believe it should be significantly less work to provide the > same sort of thing in Java. > > --Rafael
Re: [proton]: proposed change from on_credit to on_sendable
+1. I like this change. -Ted On 01/27/2015 09:53 AM, Gordon Sim wrote: The current engine examples in python make use of an OutgoingMessageHandler, that arranges for a callback to be made when the sender has credit. At present that callback is called on_credit. However I would like to change this to the slightly more general on_sendable. By being more generally applicable, it will allow for some evolution of the exact semantics (e.g. at present it takes no account of whether the socket is writable, but perhaps in future it could). - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
[proton]: proposed change from on_credit to on_sendable
The current engine examples in python make use of an OutgoingMessageHandler, that arranges for a callback to be made when the sender has credit. At present that callback is called on_credit. However I would like to change this to the slightly more general on_sendable. By being more generally applicable, it will allow for some evolution of the exact semantics (e.g. at present it takes no account of whether the socket is writable, but perhaps in future it could). - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: What is x-amqp-to?
I use this field in my 'topologist' gadget that reads topology
information from a network of qdrouters.
I only have a connection to router A, but I am able to make topo
requests of the other routers (after I learn their names) by setting
the x-amqp-to field to a value like "amqp:/_topo/0/QDR.B" .
This causes my local router to forward the request to router B
(to which I have no connection), B consumes the request,
and I get the answer back.
- Original Message -
> On 01/23/2015 01:53 PM, Alan Conway wrote:
> > I'm trying to determine if the message header x-amqp-to has any use or
> > if it's a historical leftover. Here's what I found in the 3 qpid
> > projects:
> >
> > == proton
> > == dispatch
> > doc/book/release-0.1.md:request.setProperty("x-amqp-to",
> > "amqp:/_local/$management");
> > doc/book/using.md:request.setProperty("x-amqp-to",
> > "amqp:/_local/$management");
> > == qpid
> > qpid/cpp/AMQP_1.0:for the header section, and x-amqp-to,
> > x-amqp-absolute-expiry-time,
> > qpid/cpp/src/qpid/messaging/amqp/EncodedMessage.cpp:
> > map["x-amqp-to"] = to.str();
> > qpid/cpp/src/qpid/messaging/amqp/SenderContext.cpp:const std::string
> > X_AMQP_TO("x-amqp-to");
> >
> > I believe the dispatch documentation references are incorrect and should
> > be setting the normal "to" address for the message, not the x-amqp-to
> > property. I'll test that and correct if its the case.
> >
> > I followed the bread crumbs in the qpid code base and all I could find
> > was (a lot of) code for propagating this property along the message
> > encoding and transformation path and making it available in the Message
> > API. I couldn't find any code that actually *uses* it.
> >
> > Does anyone know if I'm missing something or can we get rid of it
> > entirely?
>
> The qpid::messaging::Message class has no 'to' field. However the AMQP
> 1.0 specification does have such a field in the properties section. The
> 'x-amqp-to' label is a special key allowing the AMQP 1.0 field to be
> accessed (for both incoming and outgoing messages) as a special property
> (via Message::getProperty()/setProperty()).
>
> It should not be needed outside the qpid::messaging client (but within
> that it is still needed).
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
[proton]: proposed change to send in engine examples
The engine examples in python currently use a special send_msg() method that is dynamically added to the sender objects created by the 'container'. I never really liked this mechanism, it was just a short term workaround to get the simplicity I wanted to expose without requiring changes to the engine itself. That was useful when still on a branch, but now I'd like to see if we can find a better approach that keeps the simplicity I'm looking for, the flexibility already present in the engine api and is more intuitive and usable all round. I've proposed a change here: https://reviews.apache.org/r/30318/ That just focuses on the change to the engine. If accepted, the examples would all also change to use send() instead of send_msg(). Though on the face a simple change this would actually be a bigger improvement under the covers and would allow the same method to be used for sending messages over links established by the peer also. Comments welcome here or on the reviewboard. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Any ETA on a QPid 0.32 release
I strongly agree with Keith that any change to the source tree should happen (immediately) after (branching for) the next release. We can have separate people managing the different components if we like, but I think for this release we would be looking at a single release date and running the existing release scripts. After this release we can work out exactly how we want to release each component separately. In terms of numbering, I'm relatively relaxed as to whether we change now or at the next release - I don't think the two changes have to be coincident. As an aside, in terms of release numbering, somewhat coincidentally this will be (if I have calculated this correctly) the 15th release of Qpid since graduation (the first release was 0.5, then 0.6 and thereafter we always incremented by 0.2), so calling this release 15.1 (as the first release after an arbitrary rebasing of the version numbers) would be fine by me :-) -- Rob On 23 January 2015 at 15:54, Keith W wrote: > Hi Justin > > I'm in agreement with the plan to reorganise the source tree in the way you > describe (and expect that we would want a similar change for java) but am I > concerned about the timing of such a big change.We should be > reorganising trunk just *after* a release branch to give us plenty of time > to work through the inevitable unexpected consequences properly. > > I am in favour of having one more qpid-wide release (and I would suggest we > stick with our existing numbering scheme i.e. 0.32), then split the source > tree and adopt the new numbering convention for the next -modular- > releases. > > Thoughts? > > cheers, Keith. > > > > > On 21 January 2015 at 12:35, Justin Ross wrote: > > > Hi, Keith. > > > > Apart from picking an approach for version numbers, I don't think there > is > > anything that should prevent you from starting an independent Java > release. > > > > I've put some of my thoughts regarding source-tree organization down in > > the wiki. Please feel free to add your own. > > > > > > > https://cwiki.apache.org/confluence/display/qpid/Source+tree+layout+proposal > > > > Whatever we decide on, we don't have to do it all at once in a big bang. > > We can incrementally move modules into a new structure. > > > > Justin > > > > > > On Fri, Jan 9, 2015 at 4:34 AM, Keith W wrote: > > > >> Hi all, > >> > >> Looking through this thread, it is not clear that we came to a settled > >> position for release numbering, and when exactly we'd would move to > >> releasing components independently. On the java side we are getting > to a > >> position where a release soon would be sensible. How best do we go > >> forward? > >> > >> I'll be ready to put in some time helping plan/make the changes to the > >> release system happen, once we agree what that direction should be. > >> > >> Kind regards, Keith. > >> > >> > >> > >> On 3 December 2014 at 15:15, Robbie Gemmell > >> wrote: > >> > >> > In addition to [point] releases not actually occuring at the time the > >> > version suggests, for me another downside of using the Year.Month > >> > approach is that it doesnt as clearly convey a sense of impact for the > >> > changes involved in the release, i.e is it a major or minor release, > >> > are there any compatibility considerations etc. It might for a bugfix > >> > release, e.g 15.1.1 vs 15.1, however should 16.1 be expected to be > >> > majorly different than 15.12 or not, given it might have nearly 2 > >> > months of changes in it, or possibly just days? If it isnt, > >> > could/should it have been labeled 15.12.1 instead (at which point, > >> > back to that naming vs timing issue)? Obviously we dont convey that > >> > sort of information with the current versions, but it would be nice to > >> > start. > >> > > >> > The major example of Year.Month naming that springs to mind for me is > >> > Ubuntu, which isnt really quite the same situations since their > >> > releases are mostly a distribution of other components, whicht are all > >> > versioned independently and can often be updated to an extent between > >> > the containing Year.Month distribution releases. I can't immediately > >> > think of seeing any Apache projects using it as a convention, but I > >> > assume there are some. > >> > > >> > Robbie > >> > > >> > On 3 December 2014 at 11:50, Rob Godfrey > >> wrote: > >> > > Agreed - we'd use target date. > >> > > > >> > > To Robbie's earlier comment on point releases, we (Java side) might > >> then > >> > > subsequently release a 15.1.1 as a bugfix release of 15.1, where the > >> next > >> > > scheduled release would be a 15.5 or whatever (ideally on the java > >> side I > >> > > think we'd like to move to more frequent releases, but that's a > >> separate > >> > > issue). > >> > > > >> > > -- Rob > >> > > > >> > > On 3 December 2014 at 12:21, Gordon Sim wrote: > >> > > > >> > >> On 12/03/2014 11:02 AM, Justin Ross wrote: > >> > >> > >> > >>> On Wed, Dec 3, 2014 at 5:00 AM, Gordon Sim > wrote: > >>
