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:
> Auth
+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
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
+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).
>
> --Ra
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 work
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
min
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.
>
> O
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)
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
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
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
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 sh
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:
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
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 f
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 distrib
16 matches
Mail list logo
