Re: svn commit: r1402510 - in /qpid/proton/trunk: examples/broker/ examples/mailbox/ proton-c/ proton-c/bindings/php/ proton-c/bindings/php/examples/ proton-c/bindings/python/ proton-c/bindings/ruby/
It doesnt really affect the release since the files are now licenced, but the diff below suggests the header wasn't added to the Java files where we normally put it (at the top of the file), it would be nice if they were consistent with the others. Robbie On 26 October 2012 14:42, wrote: > Author: rajith > Date: Fri Oct 26 13:42:54 2012 > New Revision: 1402510 > > URL: http://svn.apache.org/viewvc?rev=1402510&view=rev > Log: > NO_JIRA Added missing license headers based on the RAT output > > Modified: > qpid/proton/trunk/examples/broker/example-nodes > qpid/proton/trunk/examples/mailbox/ssl-setup.sh > qpid/proton/trunk/proton-c/CMakeLists.txt > qpid/proton/trunk/proton-c/bindings/php/cproton.ini > qpid/proton/trunk/proton-c/bindings/php/examples/client.php > qpid/proton/trunk/proton-c/bindings/php/examples/server.php > qpid/proton/trunk/proton-c/bindings/php/get_include_dir.php > qpid/proton/trunk/proton-c/bindings/php/php.i > qpid/proton/trunk/proton-c/bindings/php/tests.php > qpid/proton/trunk/proton-c/bindings/python/CMakeLists.txt > qpid/proton/trunk/proton-c/bindings/python/python.i > qpid/proton/trunk/proton-c/bindings/ruby/ruby.i > qpid/proton/trunk/proton-c/docs/api/user.doxygen.in > qpid/proton/trunk/proton-c/include/proton/cproton.i > qpid/proton/trunk/proton-c/src/libqpid-proton.pc.in > qpid/proton/trunk/proton-c/src/sasl/sasl-internal.h > > qpid/proton/trunk/proton-j/src/main/java/org/apache/qpid/proton/codec/CompositeWritableBuffer.java > > qpid/proton/trunk/proton-j/src/main/java/org/apache/qpid/proton/engine/EndpointError.java > > qpid/proton/trunk/proton-j/src/main/java/org/apache/qpid/proton/engine/EndpointState.java > > qpid/proton/trunk/proton-j/src/main/java/org/apache/qpid/proton/engine/Sasl.java > > qpid/proton/trunk/proton-j/src/main/java/org/apache/qpid/proton/engine/SaslClient.java > > qpid/proton/trunk/proton-j/src/main/java/org/apache/qpid/proton/engine/SaslServer.java > > qpid/proton/trunk/proton-j/src/main/java/org/apache/qpid/proton/engine/impl/EndpointImplQuery.java > > qpid/proton/trunk/proton-j/src/main/java/org/apache/qpid/proton/engine/impl/LinkNode.java > > qpid/proton/trunk/proton-j/src/main/java/org/apache/qpid/proton/engine/impl/SaslClientImpl.java > > qpid/proton/trunk/proton-j/src/main/java/org/apache/qpid/proton/engine/impl/SaslImpl.java > > qpid/proton/trunk/proton-j/src/main/java/org/apache/qpid/proton/engine/impl/SaslServerImpl.java > > qpid/proton/trunk/proton-j/src/main/java/org/apache/qpid/proton/message/Message.java > > qpid/proton/trunk/proton-j/src/main/java/org/apache/qpid/proton/message/MessageFormat.java > > qpid/proton/trunk/proton-j/src/main/java/org/apache/qpid/proton/type/messaging/Outcome.java > > qpid/proton/trunk/proton-j/src/main/java/org/apache/qpid/proton/type/transport/FrameBody.java > > qpid/proton/trunk/proton-j/src/main/java/org/apache/qpid/proton/type/transport/Source.java > > qpid/proton/trunk/proton-j/src/main/java/org/apache/qpid/proton/type/transport/Target.java > > Modified: qpid/proton/trunk/examples/broker/example-nodes > URL: > http://svn.apache.org/viewvc/qpid/proton/trunk/examples/broker/example-nodes?rev=1402510&r1=1402509&r2=1402510&view=diff > > == > --- qpid/proton/trunk/examples/broker/example-nodes (original) > +++ qpid/proton/trunk/examples/broker/example-nodes Fri Oct 26 13:42:54 > 2012 > @@ -1,3 +1,22 @@ > +# > +# Licensed to the Apache Software Foundation (ASF) under one > +# or more contributor license agreements. See the NOTICE file > +# distributed with this work for additional information > +# regarding copyright ownership. The ASF licenses this file > +# to you under the Apache License, Version 2.0 (the > +# "License"); you may not use this file except in compliance > +# with the License. You may obtain a copy of the License at > +# > +# http://www.apache.org/licenses/LICENSE-2.0 > +# > +# Unless required by applicable law or agreed to in writing, > +# software distributed under the License is distributed on an > +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY > +# KIND, either express or implied. See the License for the > +# specific language governing permissions and limitations > +# under the License. > +# > + > from queue import Queue > from hole import Hole > > > Modified: qpid/proton/trunk/examples/mailbox/ssl-setup.sh > URL: > http://svn.apache.org/viewvc/qpid/proton/trunk/examples/mailbox/ssl-setup.sh?rev=1402510&r1=1402509&r2=1402510&view=diff > > == > --- qpid/proton/trunk/examples/mailbox/ssl-setup.sh (original) > +++ qpid/proton/trunk/examples/mailbox/ssl-setup.sh Fri Oct 26 13:42:54 > 2012 > @@ -1,3 +1,23 @@ > +# > +# > +# Licensed to the Apache Software Foundation (ASF) under one > +# or more contributor license agreements. See the NOTICE file > +# distributed with
Re: acks for messenger
+1 I like the separation. And the analogy to tracking is not only palatable but also kinda proves out the idea. William - Original Message - > I like option 2) for two reasons. One, it produces very > straightforward > semantics for the various levels of delivery guarantee. Two, it's > easy to > ignore if you'd like: if you just want fire-and-forget messaging, you > don't have to engage delivery as an api concept; if you later change > your > mind, it's not hard to level up. > > Justin > > On Fri, 26 Oct 2012, Rafael Schloming wrote: > > > I'm taking a look at expanding the messenger API to support > > reliability and so far there seem to be two directions to explore > > which I'll attempt to describe below: > > > > Option 1) > > > > Messenger.ack(Message) or possibly Message.ack() > > > > I'll describe this as the simple/expected/conservative option, and > > those really are its strong points. Some less desirable points are > > that it takes the Message concept in a bit of a different > > direction > > from where it is now. Message is no longer simply a holder of > > content, but it is also now (at least internally) tracking some > > kind > > of delivery state. This is undesirable from a design perspective > > since you're really merging two separate concepts here, delivery > > state and message content, e.g. you now end up holding onto the > > message content to track the delivery state when arguablly the > > common case is that an app will be done processing the content > > quickly but may care about the delivery state for longer. Another > > implication of this merging is that it makes messages harder to > > reuse, e.g. imagine if you want to receive a message, mutate it a > > bit, and then resend it or send a number of similar messages. > > > > It's also potentially more work from an implementation perspective > > as the underlying model treats Message as pure content and has > > delivery factored out as a separate concept, so this would be the > > start of a bit of an impedence missmatch between layers. It's > > certainly doable, but might result in more overall code since we'd > > be expressing similar concepts in two different ways. > > > > Option 2) > > > > Introduce/surface the notion of a delivery/tracking number through > > the Messenger API, e.g.: > > > > Messenger.put(Message) -> Delivery/Tracking-Number/Whatever > > Messenger.get(Message) -> Delivery/Tracking-Number/Whatever > > > > (I'll abbreviate Delivery/Tracking-Number/Whatever as DTW for > > now.) > > > > There are a couple of choices with this option, DTW could be a > > value > > object (i.e. similar to a handle), with actions on the messenger > > itself, e.g. Messenger.ack(DTW), Messenger.status(DTW). This kind > > of > > takes the tracking number analogy and runs with it, you ask your > > messenger about the status of a given delivery via its tracking > > number. Alternatively, DTW itself could be a more action oriented > > interface with its own methods for acking/status/etc. This isn't > > necessarily an either/or as there are reasons the C API might want > > to use a handle approach even if we wish to conceptualize/surface > > DTW as more of an independent thing in the object oriented > > interfaces. > > > > On the negative side this is less traditional/expected relative to > > Option (1), and it does in total add more surface area to the API. > > On the positive side however it does provide a lot more capability > > since the same concept extends quite easily to track the state of > > outgoing deliveries. > > > > From a design perspective this is nicer for a couple of reasons, > > unlike Option (1) by keeping Message as a pure holder of content > > you > > have more flexibility with how you use the API, e.g. you can > > discard/reuse the Message but still track the status of your > > deliveries. Also, it seems likely that once the Option 1) path > > includes the ability to track the status of outgoing deliveries, > > the > > total surface area balance might fall more in favor of Option (2). > > > > A possible addendum to Option (2) suggested by Rob in order to > > deal > > with the surface area concerns is adding some kind of > > Messenger.ack() that would acknowledge all unacked deliveries > > pulled > > from the incoming queue. This would enable you to do basic acking > > without ever needing to bother with DTWs if you don't care about > > them. This could in fact be a nice place to start as it doesn't > > necessarily commit us to either path initially. > > > > FWIW, my bias right now is towards exploring Option (2). I think > > the > > fact that it is less expected is sufficiently mitigated by the fact > > that with the addendum there is a very gentle learning curve, and > > even > > if you explain all the concepts up front, the whole tracking number > > analogy makes it fairly intuitive. I can even imagine playing up > > the > > difference as
Re: acks for messenger
On Fri, Oct 26, 2012 at 11:07:38AM -0400, Rafael Schloming wrote: > FWIW, my bias right now is towards exploring Option (2). I think the > fact that it is less expected is sufficiently mitigated by the fact > that with the addendum there is a very gentle learning curve, and even > if you explain all the concepts up front, the whole tracking number > analogy makes it fairly intuitive. I can even imagine playing up the > difference as a selling point from a technical marketing perspective. +1 to option 2 as well for me. Since Messenger is the type that performs communications, then it should be the means by which acknowledgements are sent. It's a more logical place to look for that sort of functionality. -- 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/ pgp28IN7Ycz89.pgp Description: PGP signature
Re: RC7
+1 RC7 proton-c {mainly Debian6 i686 testing}
-K
- Original Message -
> Lucky number 7 posted here:
>
> http://people.apache.org/~rhs/qpid-proton-0.1rc7/
>
> Only changes from RC6 are added LICENSE headers and two minor fixes
> to the
> Java SASL implementation (PROTON-103).
>
> --Rafael
>
Re: RC7
On Fri, Oct 26, 2012 at 11:13:55AM -0400, Rafael Schloming wrote: > Lucky number 7 posted here: > > http://people.apache.org/~rhs/qpid-proton-0.1rc7/ > > Only changes from RC6 are added LICENSE headers and two minor fixes to the > Java SASL implementation (PROTON-103). Local package build worked (F17 x86_64). Koji build [1] was successful. [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=4628912 -- 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/ pgpikI1FjKaxc.pgp Description: PGP signature
Re: acks for messenger
I like option 2) for two reasons. One, it produces very straightforward semantics for the various levels of delivery guarantee. Two, it's easy to ignore if you'd like: if you just want fire-and-forget messaging, you don't have to engage delivery as an api concept; if you later change your mind, it's not hard to level up. Justin On Fri, 26 Oct 2012, Rafael Schloming wrote: I'm taking a look at expanding the messenger API to support reliability and so far there seem to be two directions to explore which I'll attempt to describe below: Option 1) Messenger.ack(Message) or possibly Message.ack() I'll describe this as the simple/expected/conservative option, and those really are its strong points. Some less desirable points are that it takes the Message concept in a bit of a different direction from where it is now. Message is no longer simply a holder of content, but it is also now (at least internally) tracking some kind of delivery state. This is undesirable from a design perspective since you're really merging two separate concepts here, delivery state and message content, e.g. you now end up holding onto the message content to track the delivery state when arguablly the common case is that an app will be done processing the content quickly but may care about the delivery state for longer. Another implication of this merging is that it makes messages harder to reuse, e.g. imagine if you want to receive a message, mutate it a bit, and then resend it or send a number of similar messages. It's also potentially more work from an implementation perspective as the underlying model treats Message as pure content and has delivery factored out as a separate concept, so this would be the start of a bit of an impedence missmatch between layers. It's certainly doable, but might result in more overall code since we'd be expressing similar concepts in two different ways. Option 2) Introduce/surface the notion of a delivery/tracking number through the Messenger API, e.g.: Messenger.put(Message) -> Delivery/Tracking-Number/Whatever Messenger.get(Message) -> Delivery/Tracking-Number/Whatever (I'll abbreviate Delivery/Tracking-Number/Whatever as DTW for now.) There are a couple of choices with this option, DTW could be a value object (i.e. similar to a handle), with actions on the messenger itself, e.g. Messenger.ack(DTW), Messenger.status(DTW). This kind of takes the tracking number analogy and runs with it, you ask your messenger about the status of a given delivery via its tracking number. Alternatively, DTW itself could be a more action oriented interface with its own methods for acking/status/etc. This isn't necessarily an either/or as there are reasons the C API might want to use a handle approach even if we wish to conceptualize/surface DTW as more of an independent thing in the object oriented interfaces. On the negative side this is less traditional/expected relative to Option (1), and it does in total add more surface area to the API. On the positive side however it does provide a lot more capability since the same concept extends quite easily to track the state of outgoing deliveries. From a design perspective this is nicer for a couple of reasons, unlike Option (1) by keeping Message as a pure holder of content you have more flexibility with how you use the API, e.g. you can discard/reuse the Message but still track the status of your deliveries. Also, it seems likely that once the Option 1) path includes the ability to track the status of outgoing deliveries, the total surface area balance might fall more in favor of Option (2). A possible addendum to Option (2) suggested by Rob in order to deal with the surface area concerns is adding some kind of Messenger.ack() that would acknowledge all unacked deliveries pulled from the incoming queue. This would enable you to do basic acking without ever needing to bother with DTWs if you don't care about them. This could in fact be a nice place to start as it doesn't necessarily commit us to either path initially. FWIW, my bias right now is towards exploring Option (2). I think the fact that it is less expected is sufficiently mitigated by the fact that with the addendum there is a very gentle learning curve, and even if you explain all the concepts up front, the whole tracking number analogy makes it fairly intuitive. I can even imagine playing up the difference as a selling point from a technical marketing perspective. --Rafael
Re: acks for messenger
On 26 October 2012 17:14, Rob Godfrey wrote: > So, for me I probably started out being biased to Option 1) from a > "simplicity" standpoint, but I'm now leaning towards option 2), though > I'm not quite sure what form the DTW should take, nor how it would be > best presented in the Java API. > > One other issue that makes me uncomfortable with Option 1) it is that > by adding .ack() or even (per a previous JIRA) .getSubscription() to > Message we're potentially tying Message directly into Messenger which > is not a dependency I really want to introduce. If we stick with > Messenger as a value object then we don't have any such coupling Clearly I meant *Message* as a value object (really shouldn't try to e-mail, IM and have a conf call at the same time :-) )... -- Rob > (Messenger depends on Message, but not vice versa). > > -- Rob > > On 26 October 2012 17:07, Rafael Schloming wrote: >> I'm taking a look at expanding the messenger API to support >> reliability and so far there seem to be two directions to explore >> which I'll attempt to describe below: >> >> Option 1) >> >> Messenger.ack(Message) or possibly Message.ack() >> >> I'll describe this as the simple/expected/conservative option, and >> those really are its strong points. Some less desirable points are >> that it takes the Message concept in a bit of a different direction >> from where it is now. Message is no longer simply a holder of >> content, but it is also now (at least internally) tracking some kind >> of delivery state. This is undesirable from a design perspective >> since you're really merging two separate concepts here, delivery >> state and message content, e.g. you now end up holding onto the >> message content to track the delivery state when arguablly the >> common case is that an app will be done processing the content >> quickly but may care about the delivery state for longer. Another >> implication of this merging is that it makes messages harder to >> reuse, e.g. imagine if you want to receive a message, mutate it a >> bit, and then resend it or send a number of similar messages. >> >> It's also potentially more work from an implementation perspective >> as the underlying model treats Message as pure content and has >> delivery factored out as a separate concept, so this would be the >> start of a bit of an impedence missmatch between layers. It's >> certainly doable, but might result in more overall code since we'd >> be expressing similar concepts in two different ways. >> >> Option 2) >> >> Introduce/surface the notion of a delivery/tracking number through >> the Messenger API, e.g.: >> >> Messenger.put(Message) -> Delivery/Tracking-Number/Whatever >> Messenger.get(Message) -> Delivery/Tracking-Number/Whatever >> >> (I'll abbreviate Delivery/Tracking-Number/Whatever as DTW for now.) >> >> There are a couple of choices with this option, DTW could be a value >> object (i.e. similar to a handle), with actions on the messenger >> itself, e.g. Messenger.ack(DTW), Messenger.status(DTW). This kind of >> takes the tracking number analogy and runs with it, you ask your >> messenger about the status of a given delivery via its tracking >> number. Alternatively, DTW itself could be a more action oriented >> interface with its own methods for acking/status/etc. This isn't >> necessarily an either/or as there are reasons the C API might want >> to use a handle approach even if we wish to conceptualize/surface >> DTW as more of an independent thing in the object oriented >> interfaces. >> >> On the negative side this is less traditional/expected relative to >> Option (1), and it does in total add more surface area to the API. >> On the positive side however it does provide a lot more capability >> since the same concept extends quite easily to track the state of >> outgoing deliveries. >> >> From a design perspective this is nicer for a couple of reasons, >> unlike Option (1) by keeping Message as a pure holder of content you >> have more flexibility with how you use the API, e.g. you can >> discard/reuse the Message but still track the status of your >> deliveries. Also, it seems likely that once the Option 1) path >> includes the ability to track the status of outgoing deliveries, the >> total surface area balance might fall more in favor of Option (2). >> >> A possible addendum to Option (2) suggested by Rob in order to deal >> with the surface area concerns is adding some kind of >> Messenger.ack() that would acknowledge all unacked deliveries pulled >> from the incoming queue. This would enable you to do basic acking >> without ever needing to bother with DTWs if you don't care about >> them. This could in fact be a nice place to start as it doesn't >> necessarily commit us to either path initially. >> >> FWIW, my bias right now is towards exploring Option (2). I think the >> fact that it is less expected is suffici
Re: acks for messenger
So, for me I probably started out being biased to Option 1) from a "simplicity" standpoint, but I'm now leaning towards option 2), though I'm not quite sure what form the DTW should take, nor how it would be best presented in the Java API. One other issue that makes me uncomfortable with Option 1) it is that by adding .ack() or even (per a previous JIRA) .getSubscription() to Message we're potentially tying Message directly into Messenger which is not a dependency I really want to introduce. If we stick with Messenger as a value object then we don't have any such coupling (Messenger depends on Message, but not vice versa). -- Rob On 26 October 2012 17:07, Rafael Schloming wrote: > I'm taking a look at expanding the messenger API to support > reliability and so far there seem to be two directions to explore > which I'll attempt to describe below: > > Option 1) > > Messenger.ack(Message) or possibly Message.ack() > > I'll describe this as the simple/expected/conservative option, and > those really are its strong points. Some less desirable points are > that it takes the Message concept in a bit of a different direction > from where it is now. Message is no longer simply a holder of > content, but it is also now (at least internally) tracking some kind > of delivery state. This is undesirable from a design perspective > since you're really merging two separate concepts here, delivery > state and message content, e.g. you now end up holding onto the > message content to track the delivery state when arguablly the > common case is that an app will be done processing the content > quickly but may care about the delivery state for longer. Another > implication of this merging is that it makes messages harder to > reuse, e.g. imagine if you want to receive a message, mutate it a > bit, and then resend it or send a number of similar messages. > > It's also potentially more work from an implementation perspective > as the underlying model treats Message as pure content and has > delivery factored out as a separate concept, so this would be the > start of a bit of an impedence missmatch between layers. It's > certainly doable, but might result in more overall code since we'd > be expressing similar concepts in two different ways. > > Option 2) > > Introduce/surface the notion of a delivery/tracking number through > the Messenger API, e.g.: > > Messenger.put(Message) -> Delivery/Tracking-Number/Whatever > Messenger.get(Message) -> Delivery/Tracking-Number/Whatever > > (I'll abbreviate Delivery/Tracking-Number/Whatever as DTW for now.) > > There are a couple of choices with this option, DTW could be a value > object (i.e. similar to a handle), with actions on the messenger > itself, e.g. Messenger.ack(DTW), Messenger.status(DTW). This kind of > takes the tracking number analogy and runs with it, you ask your > messenger about the status of a given delivery via its tracking > number. Alternatively, DTW itself could be a more action oriented > interface with its own methods for acking/status/etc. This isn't > necessarily an either/or as there are reasons the C API might want > to use a handle approach even if we wish to conceptualize/surface > DTW as more of an independent thing in the object oriented > interfaces. > > On the negative side this is less traditional/expected relative to > Option (1), and it does in total add more surface area to the API. > On the positive side however it does provide a lot more capability > since the same concept extends quite easily to track the state of > outgoing deliveries. > > From a design perspective this is nicer for a couple of reasons, > unlike Option (1) by keeping Message as a pure holder of content you > have more flexibility with how you use the API, e.g. you can > discard/reuse the Message but still track the status of your > deliveries. Also, it seems likely that once the Option 1) path > includes the ability to track the status of outgoing deliveries, the > total surface area balance might fall more in favor of Option (2). > > A possible addendum to Option (2) suggested by Rob in order to deal > with the surface area concerns is adding some kind of > Messenger.ack() that would acknowledge all unacked deliveries pulled > from the incoming queue. This would enable you to do basic acking > without ever needing to bother with DTWs if you don't care about > them. This could in fact be a nice place to start as it doesn't > necessarily commit us to either path initially. > > FWIW, my bias right now is towards exploring Option (2). I think the > fact that it is less expected is sufficiently mitigated by the fact > that with the addendum there is a very gentle learning curve, and even > if you explain all the concepts up front, the whole tracking number > analogy makes it fairly intuitive. I can even imagine playing up the > difference as a selling point from a techn
RC7
Lucky number 7 posted here: http://people.apache.org/~rhs/qpid-proton-0.1rc7/ Only changes from RC6 are added LICENSE headers and two minor fixes to the Java SASL implementation (PROTON-103). --Rafael
acks for messenger
I'm taking a look at expanding the messenger API to support reliability and so far there seem to be two directions to explore which I'll attempt to describe below: Option 1) Messenger.ack(Message) or possibly Message.ack() I'll describe this as the simple/expected/conservative option, and those really are its strong points. Some less desirable points are that it takes the Message concept in a bit of a different direction from where it is now. Message is no longer simply a holder of content, but it is also now (at least internally) tracking some kind of delivery state. This is undesirable from a design perspective since you're really merging two separate concepts here, delivery state and message content, e.g. you now end up holding onto the message content to track the delivery state when arguablly the common case is that an app will be done processing the content quickly but may care about the delivery state for longer. Another implication of this merging is that it makes messages harder to reuse, e.g. imagine if you want to receive a message, mutate it a bit, and then resend it or send a number of similar messages. It's also potentially more work from an implementation perspective as the underlying model treats Message as pure content and has delivery factored out as a separate concept, so this would be the start of a bit of an impedence missmatch between layers. It's certainly doable, but might result in more overall code since we'd be expressing similar concepts in two different ways. Option 2) Introduce/surface the notion of a delivery/tracking number through the Messenger API, e.g.: Messenger.put(Message) -> Delivery/Tracking-Number/Whatever Messenger.get(Message) -> Delivery/Tracking-Number/Whatever (I'll abbreviate Delivery/Tracking-Number/Whatever as DTW for now.) There are a couple of choices with this option, DTW could be a value object (i.e. similar to a handle), with actions on the messenger itself, e.g. Messenger.ack(DTW), Messenger.status(DTW). This kind of takes the tracking number analogy and runs with it, you ask your messenger about the status of a given delivery via its tracking number. Alternatively, DTW itself could be a more action oriented interface with its own methods for acking/status/etc. This isn't necessarily an either/or as there are reasons the C API might want to use a handle approach even if we wish to conceptualize/surface DTW as more of an independent thing in the object oriented interfaces. On the negative side this is less traditional/expected relative to Option (1), and it does in total add more surface area to the API. On the positive side however it does provide a lot more capability since the same concept extends quite easily to track the state of outgoing deliveries. From a design perspective this is nicer for a couple of reasons, unlike Option (1) by keeping Message as a pure holder of content you have more flexibility with how you use the API, e.g. you can discard/reuse the Message but still track the status of your deliveries. Also, it seems likely that once the Option 1) path includes the ability to track the status of outgoing deliveries, the total surface area balance might fall more in favor of Option (2). A possible addendum to Option (2) suggested by Rob in order to deal with the surface area concerns is adding some kind of Messenger.ack() that would acknowledge all unacked deliveries pulled from the incoming queue. This would enable you to do basic acking without ever needing to bother with DTWs if you don't care about them. This could in fact be a nice place to start as it doesn't necessarily commit us to either path initially. FWIW, my bias right now is towards exploring Option (2). I think the fact that it is less expected is sufficiently mitigated by the fact that with the addendum there is a very gentle learning curve, and even if you explain all the concepts up front, the whole tracking number analogy makes it fairly intuitive. I can even imagine playing up the difference as a selling point from a technical marketing perspective. --Rafael
Re: RC6
On Thu, Oct 25, 2012 at 08:38:04PM -0400, Rafael Schloming wrote: > I put up an RC6 here[1] with the java shim fixed so the SSL tests skip > properly. That's the only change from RC5. > > [1] http://people.apache.org/~rhs/qpid-proton-0.1rc6/ Packages build fine locally (F17 x86_64). Scratch build in Koji [1] was successful as well. [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=4628740 -- 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/ pgp7Fso70zc9R.pgp Description: PGP signature
Re: RC6
I have forwarded you (and the pmc) the original email from committers@ with the details. Robbie On 26 October 2012 14:48, Rafael Schloming wrote: > Do you know how I get my key to show up there? > > --Rafael > > On Fri, Oct 26, 2012 at 5:30 AM, Robbie Gemmell >wrote: > > > I dont think KEYS should be proton specific, its just the Qpid committers > > and should be the same file as a result. Commons-* seem to use the same > > KEYS file for example. > > > > (Aside: we should probably be transitioning away from the KEYS file > anyway > > and using the new system they put in place for distribution via > > https://people.apache.org/keys/). > > > > Robbie > > > > On 26 October 2012 02:05, Rajith Attapattu wrote: > > > > > Sorry I should have done this before you posted RC6 :( > > > We have a few files (mostly java files) that are missing license > headers. > > > Please look at the RAT output I posted. > > > > > > Once the final RC is voted, the release manager (in this case Rafi) > > > will have to sign the final artefacts. > > > You already have your key listed here [1] > > > We should move [1] under the proton main dir. > > > > > > Regards, > > > > > > Rajith > > > > > > [1] https://svn.apache.org/repos/asf/qpid/trunk/qpid/KEYS > > > > > > On Thu, Oct 25, 2012 at 8:38 PM, Rafael Schloming > > > wrote: > > > > I put up an RC6 here[1] with the java shim fixed so the SSL tests > skip > > > > properly. That's the only change from RC5. > > > > > > > > [1] http://people.apache.org/~rhs/qpid-proton-0.1rc6/ > > > > > > > > --Rafael > > > > > >
Re: RAT output for Proton
I have now added the missing license headers. Updated RAT output here [1] I used the following options in case someone wants to try it in the future. -e *gitignore -e *xml -e TODO -e README* -e *html -e EXAMPLES -d Regards, Rajith [1] http://creadur.apache.org/rat/ On Thu, Oct 25, 2012 at 9:01 PM, Rajith Attapattu wrote: > The following RAT output shows that we are missing a few license > headers, mostly java files. > > http://people.apache.org/~rajith/proton/proton-rat-output.txt > > We need to fix them before releasing. > Unfortunately I need to step out now. > If somebody hasn't gotten to it by tomorrow morning, I can take care of it. > > Regards, > > Rajith > > P.S There is an option in RAT "-a" that will automatically add the > license header. > This could potentially mess up cmake files. So be careful :) > > [1] http://creadur.apache.org/rat/ > [2] http://people.apache.org/~rajith/proton/proton-rat-output.txt
Re: RC6
Do you know how I get my key to show up there? --Rafael On Fri, Oct 26, 2012 at 5:30 AM, Robbie Gemmell wrote: > I dont think KEYS should be proton specific, its just the Qpid committers > and should be the same file as a result. Commons-* seem to use the same > KEYS file for example. > > (Aside: we should probably be transitioning away from the KEYS file anyway > and using the new system they put in place for distribution via > https://people.apache.org/keys/). > > Robbie > > On 26 October 2012 02:05, Rajith Attapattu wrote: > > > Sorry I should have done this before you posted RC6 :( > > We have a few files (mostly java files) that are missing license headers. > > Please look at the RAT output I posted. > > > > Once the final RC is voted, the release manager (in this case Rafi) > > will have to sign the final artefacts. > > You already have your key listed here [1] > > We should move [1] under the proton main dir. > > > > Regards, > > > > Rajith > > > > [1] https://svn.apache.org/repos/asf/qpid/trunk/qpid/KEYS > > > > On Thu, Oct 25, 2012 at 8:38 PM, Rafael Schloming > > wrote: > > > I put up an RC6 here[1] with the java shim fixed so the SSL tests skip > > > properly. That's the only change from RC5. > > > > > > [1] http://people.apache.org/~rhs/qpid-proton-0.1rc6/ > > > > > > --Rafael > > >
Re: RC6
On Fri, Oct 26, 2012 at 5:30 AM, Robbie Gemmell wrote: > I dont think KEYS should be proton specific, its just the Qpid committers > and should be the same file as a result. Commons-* seem to use the same > KEYS file for example. > > (Aside: we should probably be transitioning away from the KEYS file anyway > and using the new system they put in place for distribution via > https://people.apache.org/keys/). > Sorry I haven't looked at this stuff for a while now, so wasn't aware about the new mechanism. The existing KEYS file was inside the qpid tree, hence my suggestion. Actually a better suggestion would have been to move that file to the top level. But anyways, given that we have a new system in place it's irrelevant now. We should make an attempt to use the new approach. Rajith > Robbie > > On 26 October 2012 02:05, Rajith Attapattu wrote: > >> Sorry I should have done this before you posted RC6 :( >> We have a few files (mostly java files) that are missing license headers. >> Please look at the RAT output I posted. >> >> Once the final RC is voted, the release manager (in this case Rafi) >> will have to sign the final artefacts. >> You already have your key listed here [1] >> We should move [1] under the proton main dir. >> >> Regards, >> >> Rajith >> >> [1] https://svn.apache.org/repos/asf/qpid/trunk/qpid/KEYS >> >> On Thu, Oct 25, 2012 at 8:38 PM, Rafael Schloming >> wrote: >> > I put up an RC6 here[1] with the java shim fixed so the SSL tests skip >> > properly. That's the only change from RC5. >> > >> > [1] http://people.apache.org/~rhs/qpid-proton-0.1rc6/ >> > >> > --Rafael >>
Re: RC6
I dont think KEYS should be proton specific, its just the Qpid committers and should be the same file as a result. Commons-* seem to use the same KEYS file for example. (Aside: we should probably be transitioning away from the KEYS file anyway and using the new system they put in place for distribution via https://people.apache.org/keys/). Robbie On 26 October 2012 02:05, Rajith Attapattu wrote: > Sorry I should have done this before you posted RC6 :( > We have a few files (mostly java files) that are missing license headers. > Please look at the RAT output I posted. > > Once the final RC is voted, the release manager (in this case Rafi) > will have to sign the final artefacts. > You already have your key listed here [1] > We should move [1] under the proton main dir. > > Regards, > > Rajith > > [1] https://svn.apache.org/repos/asf/qpid/trunk/qpid/KEYS > > On Thu, Oct 25, 2012 at 8:38 PM, Rafael Schloming > wrote: > > I put up an RC6 here[1] with the java shim fixed so the SSL tests skip > > properly. That's the only change from RC5. > > > > [1] http://people.apache.org/~rhs/qpid-proton-0.1rc6/ > > > > --Rafael >
