Hi Everyone,
I've done some exploratory coding on a small refactor aimed at simplifying
the driver in order to ease both portability and ssl integration. I've
attached the patch. It's not huge, but it removes some of the trickiest
code from driver.c. I believe there are further simplifications
Oops, looks like attachments are stripped. I've posted the patch here:
https://reviews.apache.org/r/6910/
--Rafael
the current byte transport as a layer on top of that.
--Rafael
On Tue, Sep 4, 2012 at 9:59 PM, Rajith Attapattu rajit...@gmail.com wrote:
On Tue, Sep 4, 2012 at 9:16 PM, Rafael Schloming r...@alum.mit.edu wrote:
On Tue, Sep 4, 2012 at 5:53 PM, Rajith Attapattu rajit...@gmail.com
wrote:
I'm
Hi Everyone,
Sorry for the bulk edit spam. I've just added proton-j and proton-c
components to the JIRA, and retroactively put all issues in the appropriate
component. Please use the components as appropriate going forward.
Thanks,
--Rafael
This should work now with the possibly slightly unintuitive caveat that
when you load None/null/nil into a text message and then save it, you get
back an empty string.
--Rafael
On Wed, Sep 5, 2012 at 8:02 AM, Darryl L. Pierce dpie...@redhat.com wrote:
Should attempting to load a message with
As of last night this is on trunk.
--Rafael
On Thu, Sep 6, 2012 at 4:11 PM, Ken Giusti kgiu...@redhat.com wrote:
Good improvement.
Once it's on trunk I'll refactor the ssl branch to move the ssl i/o into
the transport, as per the intent.
-K
- Original Message -
On Tue, Sep 4,
Can you comment on why you decided to inline it directly into the C header
files as opposed to splitting it out somehow? Given William's comment on
exceptions, it seems like it might well expand/evolve enough to make it
awkward to inline.
--Rafael
On Mon, Sep 10, 2012 at 2:47 PM, Andrew Stitcher
Hey Everyone,
I've put together a draft of an idiomatic python API that sits on top of
the swig bindings. It's a very thin layer, all it does is translate from a
procedural interface to an object oriented one, handling memory management
and adding checked exceptions along the way. I've posted it
On Thu, Sep 13, 2012 at 9:36 AM, Justin Ross jr...@redhat.com wrote:
On Thu, 13 Sep 2012, Ted Ross wrote:
I'm not crazy about the work-processing function names as they seem to
disregard the grammar. Should they not all be pn_connection_* functions?
I agree about this. I would
Hi Mary,
Welcome to the list! I'm looking forward to seeing the issues you've hit.
It would be great to have proton working with the Visual Studio toolset. If
you have patches ready to go already our main tools for collaboration are
JIRA[1] and reviewboard[2]. Please feel free to ask questions
On Fri, Sep 28, 2012 at 6:02 PM, Andrew Stitcher astitc...@redhat.comwrote:
Ken,
When you added Openssl support to proton was there a specific reason you
detected it by hand rather than using cmake FindPackage? Also
HAVE_OPENSSL_H isn't used anywhere.
I attach attach a patch to neaten this
Hey,
I posted the api-docs on the web site here:
http://qpid.apache.org/proton/api-doc/
Right now it's just based on a recent snapshot, but hopefully soon I can
set up some kind of automated update.
--Rafael
On Wed, Oct 24, 2012 at 8:20 AM, Rob Godfrey rob.j.godf...@gmail.comwrote:
The proton-j package doesn't seem to have a README or a LICENSE file
included. The maven build can't run the tests as the directory
structure doesn't include all the necessary files (nor does it have
the same
...@redhat.comwrote:
On Wed, Oct 24, 2012 at 08:19:34AM -0400, Rafael Schloming wrote:
I've uploaded another release candidate here:
http://people.apache.org/~rhs/qpid-proton-0.1rc2/
The following fixes were made:
1. the install step should now work without the documentation
2. the README has
I'm a little stumped by this one. I'm thinking the compiler settings must
be quite different from how we normally build, but I'm not sure why.
--Rafael
On Wed, Oct 24, 2012 at 11:03 AM, Darryl L. Pierce dpie...@redhat.comwrote:
On Wed, Oct 24, 2012 at 10:36:11AM -0400, Rafael Schloming wrote
I've put up an RC3 here:
http://people.apache.org/~rhs/qpid-proton-0.1rc3/
The following are the changes from RC2:
- added README and LICENSE for proton-j
- updated the proton-c README
- fixed cmake build to not use the OPTIONAL thing for older versions
- fixed detection of LIB_SUFFIX
The examples should work without the config.sh, it just sets up stuff for
the dev environment. If you do the make install, all the proton stuff
should be available without any special environmental config.
--Rafael
On Wed, Oct 24, 2012 at 8:11 PM, William Henry whe...@redhat.com wrote:
Are the
Can you post the contents of your install_manifest.txt?
On Wed, Oct 24, 2012 at 9:50 PM, William Henry whe...@redhat.com wrote:
Ok install was successful. Still have an ImportError for proton.
Not sure what I'm missing
William
Sent from my iPhone
On Oct 24, 2012, at 7:29 PM, Rafael
:
Ok install was successful. Still have an ImportError for proton.
Not sure what I'm missing
William
Sent from my iPhone
On Oct 24, 2012, at 7:29 PM, Rafael Schloming r...@alum.mit.edu
wrote:
The examples should work without the config.sh, it just sets up
Ok, I'm -1ing this one because ken's ssl fix didn't make it in. Sorry for
the churn. RC5 will be up shortly with ken's ssl fix in it.
--Rafael
On Thu, Oct 25, 2012 at 1:42 PM, Rafael Schloming r...@alum.mit.edu wrote:
I've posted an RC4 here:
http://people.apache.org/~rhs/qpid-proton
Please have a look. This one includes ken's ssl fix in addition to
everything that was in RC4:
http://people.apache.org/~rhs/qpid-proton-0.1rc5/
not known)
all other tests passed
-- Rob
On 25 October 2012 22:07, Rafael Schloming r...@alum.mit.edu wrote:
Please have a look. This one includes ken's ssl fix in addition to
everything that was in RC4:
http://people.apache.org/~rhs/qpid-proton-0.1rc5/
This was my bad, I'll post an RC6 with the shim fixed.
--Rafael
On Thu, Oct 25, 2012 at 5:35 PM, Rajith Attapattu rajit...@gmail.comwrote:
We have a build failure on the java side.
It appears the SSL tests added in Kens fix is failing.
proton_tests.ssl.SslTest.test_client_authentication
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
]
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 r...@alum.mit.edu
wrote:
I put up an RC6 here[1] with the java shim fixed so the SSL tests skip
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
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
FWIW, a lot of the patches that have been made to the build system so far
were taken from the cpp broker's build and to be honest when you push for
the reason they were done that way there is sometimes a good reason and
sometimes no good reason, and sometimes a reason that doesn't apply to
proton.
Hi, I did a bit more testing over the weekend and posted an RC3 here:
http://people.apache.org/~rhs/qpid-proton-0.2rc3
The only changes are fixing a minor bug in the ack stuff and adding the C
examples. Given that the delta from 0.1 is quite contained, I'm going to
optimistically call for a
-1
Sadly I have to vote against myself due to a bug I just found. Will follow
up with RC4 presently.
--Rafael
On Sun, Nov 4, 2012 at 7:09 PM, Rafael Schloming r...@alum.mit.edu wrote:
Hi, I did a bit more testing over the weekend and posted an RC3 here:
http://people.apache.org/~rhs/qpid
Posted here: http://people.apache.org/~rhs/qpid-proton-0.2rc4/
[ ] Ship it! (Release RC4 as 0.2)
[ ] No (We need another RC because...)
The only difference between RC3 and RC4 for proton-c is a one line change
in engine.c that ensures that pn_transport_output will not fail to produce
output
On Mon, Nov 5, 2012 at 3:54 PM, Darryl L. Pierce dpie...@redhat.com wrote
Will the final, official URL for the source be:
http://www.apache.org/dist/proton/$VER/qpid-proton-c-$VER.tar.gz
? I'd like to clean up another rpmlint error where it doesn't like a
non-URI value for the source.
-c-0.1.tar.gz
--Rafael
Robbie
On 5 November 2012 16:11, Rafael Schloming r...@alum.mit.edu wrote:
On Mon, Nov 5, 2012 at 3:54 PM, Darryl L. Pierce dpie...@redhat.com
wrote
Will the final, official URL for the source be:
http://www.apache.org/dist/proton/$VER/qpid-proton-c
On Wed, Nov 14, 2012 at 10:36 PM, Ted Ross tr...@redhat.com wrote:
On 11/14/2012 12:56 PM, Rafael Schloming wrote:
On Wed, Nov 14, 2012 at 6:37 PM, Ted Ross tr...@redhat.com wrote:
On 11/14/2012 11:49 AM, Rafael Schloming wrote:
How does the packaging prevent this?
1) Develop
On Tue, Nov 20, 2012 at 2:34 PM, Darryl L. Pierce dpie...@redhat.comwrote:
Last week Justin asked me to take a look at the examples for Proton
across language bindings. What I found are the following:
C Python Ruby Perl
Mailbox (Raw API)[
On Wed, Dec 5, 2012 at 8:18 AM, Darryl L. Pierce dpie...@redhat.com wrote:
On Tue, Dec 04, 2012 at 05:24:25PM -0500, Andrew Stitcher wrote:
On Thu, 2012-11-29 at 17:16 -0500, Darryl L. Pierce wrote:
I've pushed the Perl language bindings as well as the send/recv
examples
for using the
On Wed, Dec 5, 2012 at 2:50 PM, Andrew Stitcher astitc...@redhat.comwrote:
On Wed, 2012-12-05 at 11:12 -0500, Rafael Schloming wrote:
On Wed, Dec 5, 2012 at 9:52 AM, Darryl L. Pierce dpie...@redhat.com
wrote:
On Wed, Dec 05, 2012 at 08:18:06AM -0500, Darryl L. Pierce wrote:
It seems
On Wed, Dec 5, 2012 at 4:38 PM, Darryl L. Pierce dpie...@redhat.com wrote:
On Wed, Dec 05, 2012 at 03:08:24PM -0500, Rafael Schloming wrote:
Okay, then a developer has to explicitly override the INI directory
each
time. For the EXT and INCLUDE directories it's easy to do what we're
On Thu, Dec 6, 2012 at 1:05 PM, Andrew Stitcher astitc...@redhat.comwrote:
On Wed, 2012-12-05 at 17:51 -0500, Rafael Schloming wrote:
On Wed, Dec 5, 2012 at 4:38 PM, Darryl L. Pierce dpie...@redhat.com
wrote:
I disagree:
Are you disagreeing with me or Darryl or both? ;-)
There are two
On Thu, Dec 6, 2012 at 1:35 PM, Andrew Stitcher astitc...@redhat.comwrote:
On Thu, 2012-12-06 at 13:24 -0500, Rafael Schloming wrote:
...
The best way to cater to the developer scenario you mention is to simply
look at install_manifest.txt. This file is generated whenever you type
make
On Fri, Dec 21, 2012 at 9:32 AM, Ken Giusti kgiu...@redhat.com wrote:
Ok, thanks Darryl - I'll give it a try.
In any case, the README file in the release candidate needs to be updated
- I imagine most folks just starting out with proton want to be able to
evaluate it without needing root
On Wed, Jan 2, 2013 at 11:42 AM, Darryl L. Pierce dpie...@redhat.comwrote:
On Thu, Dec 20, 2012 at 02:02:27PM -0500, Rafael Schloming wrote:
Sources posted here: http://people.apache.org/~rhs/qpid-proton-0.3rc1/
Java binaries here:
https://repository.apache.org/content/repositories
On Fri, Jan 4, 2013 at 11:04 AM, Ted Ross tr...@redhat.com wrote:
Phil,
The only shared-object in that list that is a proper library is
libqpid-proton.so. The others are extension modules for their various
scripting languages. I'm not 100% sure, but I believe that the naming
conventions
On Thu, Jan 3, 2013 at 7:11 AM, Darryl L. Pierce dpie...@redhat.com wrote:
On Wed, Jan 02, 2013 at 12:54:34PM -0500, Rafael Schloming wrote:
We need to make it a part of the release process to bump the release
number in the following files:
proton-c/CMakeLists.txt
proton-c
On Fri, Jan 4, 2013 at 2:58 PM, Phil Harvey p...@philharveyonline.comwrote:
Thanks for the responses guys. That all makes sense.
The only change that I'd propose is therefore that the Perl and Java
bindings:
bindings/perl/libcproton_perl.so bindings/java/libproton-swig.so
... should both
On Fri, Jan 4, 2013 at 3:15 PM, Darryl L. Pierce dpie...@redhat.com wrote:
On Fri, Jan 04, 2013 at 07:58:10PM +, Phil Harvey wrote:
Thanks for the responses guys. That all makes sense.
The only change that I'd propose is therefore that the Perl and Java
bindings:
On Fri, Jan 4, 2013 at 1:22 PM, Darryl L. Pierce dpie...@redhat.com wrote:
On Fri, Jan 04, 2013 at 11:21:07AM -0500, Rafael Schloming wrote:
I pushed a patch this morning that bumped the Perl and Ruby versions.
Can you please include that in RC2? Thanks.
That will be picked up
, Jan 04, 2013 at 03:32:44PM -0500, Rafael Schloming wrote:
Given what little I know of loading JNI stuff, that seems to make sense
for
Java.
FWIW, the python and ruby bindings don't ever actually expose the name
of
the C extension library since in both cases we have the so-called
Hi, I've posted a 0.3 RC2.
Sources are here: http://people.apache.org/~rhs/qpid-proton-0.3rc2/
Java binaries are here:
https://repository.apache.org/content/repositories/orgapacheqpid-102/
The following fixes have been made since RC1:
- bumped proton version numbers to 0.3
- python binding
, Rafael Schloming wrote:
Source is here:
http://people.apache.org/~rhs/**qpid-proton-0.3rc3/http://people.apache.org/~rhs/qpid-proton-0.3rc3/
Java binaries are here:
https://repository.apache.org/**content/repositories/**orgapacheqpid-118/https://repository.apache.org/content/repositories
On Mon, Jan 14, 2013 at 11:14 AM, Eagy, Taylor te...@blackbirdtech.comwrote:
Hi guys,
I've been using Qpid for the past several months and I really like it.
However, I've mainly just been using it to pass messages between several
Python processes running on the same machine, so using Qpid
On Tue, Jan 15, 2013 at 9:33 AM, Simon MacMullen si...@rabbitmq.com wrote:
Hi.
I'm interested in testing Proton against the RabbitMQ AMQP 1.0 adapter.
But I'm struggling with the APIs I need to use to write even a simple
program. I'm using the Java version but from what I can see the C
The staging repo has been released, the RCs were copied over to dist last
night, and the download page was updated this morning. I've also created a
0.3 branch.
--Rafael
On Mon, Jan 14, 2013 at 4:31 PM, Darryl L. Pierce dpie...@redhat.comwrote:
On Mon, Jan 14, 2013 at 02:14:26PM -0500, Rafael
On Mon, Jan 21, 2013 at 9:33 AM, Rob Godfrey rob.j.godf...@gmail.comwrote:
Ummm... it's a dependency... you're familiar with those, yeah?
The same way that the Qpid JMS clients depend on a JMS API jar, for which
the source is readily available from another source. The JNI binding would
build
It's really about architecture and audience and how they interact. The
architecture we are currently developing is closely modelled on the
existing architecture of the internet. At the lowest layer the TCP stack
provides a very general purpose protocol to a very wide range of
applications. This is
On Mon, Jan 21, 2013 at 8:03 AM, Robbie Gemmell robbie.gemm...@gmail.comwrote:
I would echo some of Robs points (since he beat me to saying them msyelf :)
) and add some of my own.
I also dont see a need to check out proton-c or proton-j in isolation, if
the tests for both of them sit a
, Rafael Schloming r...@alum.mit.edu wrote:
On Fri, Jan 18, 2013 at 11:17 AM, Keith W keith.w...@gmail.com wrote:
We are currently in the process of implementing the proton-jni binding
for the proton-c library that implements the Java Proton-API, allow
Java users to choose the C based
On Mon, Jan 21, 2013 at 1:42 PM, Gordon Sim g...@redhat.com wrote:
On 01/21/2013 05:22 PM, Rafael Schloming wrote:
The users of a piece of software inherently shape its
direction, and forcing two pieces of software that need to be quite
independent to have a single user group is going
On Mon, Jan 21, 2013 at 3:10 PM, Gordon Sim g...@redhat.com wrote:
On 01/21/2013 07:39 PM, Rafael Schloming wrote:
Calling it an analogy is not really being fair. Getting closer to the
level
of generality I've described has been one of if not the primary design
goal
behind AMQP 1.0 since
On Tue, Jan 22, 2013 at 4:22 AM, Rob Godfrey rob.j.godf...@gmail.comwrote:
On 21 January 2013 18:05, Rafael Schloming r...@alum.mit.edu wrote:
On Mon, Jan 21, 2013 at 9:33 AM, Rob Godfrey rob.j.godf...@gmail.com
wrote:
Ummm... it's a dependency... you're familiar with those, yeah
of these requirements?
Are there any I've missed? I think answering these questions is a
prerequisite for agreeing the technical solution.
Phil
On 22 January 2013 13:34, Rob Godfrey rob.j.godf...@gmail.com wrote:
On 22 January 2013 13:47, Rafael Schloming r...@alum.mit.edu wrote:
On Tue
Yeah, it appears to be a bug. I checked in a potential fix on trunk. Give
it a shot and see if it's still an issue.
--Rafael
On Wed, Jan 23, 2013 at 9:19 AM, Phil Harvey p...@philharveyonline.comwrote:
I'm working on the proton-c JNI binding and am having trouble with the
.
On 22 January 2013 17:09, Rafael Schloming r...@alum.mit.edu wrote:
Thanks for posting this, I think it's a very useful step. I'd suggest
adding another Stakeholder -- someone testing a release artifact. Rob
makes
a good point that the release manager is a distinct view, but I think
On Wed, Jan 23, 2013 at 8:01 AM, Keith W keith.w...@gmail.com wrote:
Essential
3. To change proton-api, all that is required is to edit a Java file.
- Developer productivity
This seems to be kind of a leading requirement so to speak, or at least
it's phrased a little bit oddly. That said I
On Wed, Jan 23, 2013 at 6:44 PM, Rob Godfrey rob.j.godf...@gmail.comwrote:
Firstly I think it would be helpful if you made clear the requirements you
consider to be essential, nice to have, unimportant and/or detrimental.
On 23 January 2013 20:17, Rafael Schloming r...@alum.mit.edu wrote
On Thu, Jan 24, 2013 at 7:38 AM, Keith W keith.w...@gmail.com wrote:
On 23 January 2013 15:40, Rafael Schloming r...@alum.mit.edu wrote:
Yeah, it appears to be a bug. I checked in a potential fix on trunk. Give
it a shot and see if it's still an issue.
--Rafael
Thanks, that has indeed
On Thu, Jan 24, 2013 at 5:06 AM, Rob Godfrey rob.j.godf...@gmail.comwrote:
On 23 January 2013 17:36, Phil Harvey p...@philharveyonline.com wrote:
As part of the Proton JNI work, I would like to remove all calls to
proton-j implementation constructors from client code. I intend that
On Fri, Jan 25, 2013 at 9:56 AM, Phil Harvey p...@philharveyonline.comwrote:
As promised, here is a proper write-up of how we're planning to modify the
Proton build system.
=== Requirements ===
I've updated the Proton build system requirements wiki page:
January 2013 20:03, Rafael Schloming r...@alum.mit.edu wrote:
On Thu, Jan 24, 2013 at 5:06 AM, Rob Godfrey
rob.j.godf...@gmail.com
wrote:
On 23 January 2013 17:36, Phil Harvey p...@philharveyonline.com
wrote:
As part of the Proton JNI work, I would like
It is definitely a supported language. The website is merely out of date,
the recent 0.3 release was the first to include the perl binding. Thanks
for noticing, I will update it shortly.
--Rafael
On Tue, Jan 29, 2013 at 3:58 AM, Lionel Cons lionel.c...@cern.ch wrote:
:32 AM, Rafael Schloming r...@alum.mit.edu
wrote:
On Fri, Jan 25, 2013 at 9:53 PM, Paul O'Fallon p...@ofallonfamily.com
wrote:
Hello! I'm new to proton (and AMQP), and have some questions about
using
the Messenger API in the C library to send messages to Windows Azure.
I've
I updated the testing diagram to include the python and C code that swig
generates. This was mostly just as an excuse to play with the tool. I
haven't used it before, but so far it seems promising. I think we could
definitely benefit from using it more.
--Rafael
On Wed, Jan 30, 2013 at 12:32 PM,
On Mon, Feb 4, 2013 at 11:36 AM, Ken Giusti kgiu...@redhat.com wrote:
I like what I'm hearing - here are some objectives based on what has been
proposed so far:
1) Messenger-based scale and soak tests.
These would be 'black-box' type tests that would mimic simple
deployment scenarios,
A recent bug (PROTON-222) has exposed an issue with the transport
interface. The details of the bug are documented in the JIRA, but the basic
issue is that given the current transport interface there is no way for an
application to discover via the engine interface when data has been
actually
On Wed, Feb 6, 2013 at 2:13 PM, Ken Giusti kgiu...@redhat.com wrote:
Rafi, I agree with the rational behind these changes.
/** Return a pointer to a transport's input buffer. This pointer
may
* change when calls into the engine are made.
I think we'll need to be a little
On Wed, Feb 6, 2013 at 2:13 PM, Ken Giusti kgiu...@redhat.com wrote:
Rafi, I agree with the rational behind these changes.
/** Return a pointer to a transport's input buffer. This pointer
may
* change when calls into the engine are made.
I think we'll need to be a little
On Wed, Feb 6, 2013 at 5:12 PM, Rafael Schloming r...@alum.mit.edu wrote:
On Wed, Feb 6, 2013 at 2:13 PM, Ken Giusti kgiu...@redhat.com wrote:
Rafi, I agree with the rational behind these changes.
/** Return a pointer to a transport's input buffer. This pointer
may
* change
now pretty much exactly matches a circular buffer (i.e. a byte queue), I
find the input/output prefixes a bit jarring.
--Rafael
On Thu, Feb 7, 2013 at 5:53 AM, Rafael Schloming r...@alum.mit.edu wrote:
On Wed, Feb 6, 2013 at 5:12 PM, Rafael Schloming r...@alum.mit.edu wrote:
On Wed, Feb 6, 2013
Looks like the attachement didn't make it. Here's the link to the patch on
JIRA:
https://issues.apache.org/jira/secure/attachment/12568408/transport.patch
--Rafael
On Thu, Feb 7, 2013 at 8:10 AM, Rafael Schloming r...@alum.mit.edu wrote:
Here's a patch to engine.h with updated docs/naming
On Thu, Feb 7, 2013 at 11:13 AM, William Henry whe...@redhat.com wrote:
This seems to require more copying, right? I'm always weary of extra
copying.
Is there a way to have a (small) pool of buffers, or just two for swapping
between, that can be used to eliminate extra copying? Does that
, Feb 7, 2013 at 8:10 AM, Rafael Schloming r...@alum.mit.edu
wrote:
Here's a patch to engine.h with updated docs/naming. I've
documented what
I believe would be future lifecycle semantics, however as I said
before I
think an initial patch would need to be more conservative. I
Unless I'm missing something, I don't think this pattern would work in the
general case. For example it's valid to set a timeout of zero, so you'd
either be stuck with no way to get a timeout without setting it, or you'd
have no way to set it back to zero once you'd set it to something else.
this won't work, then is i.e. a float value that allows the
whole numberline, but I bet we won't have any of those.
- Original Message -
From: Rafael Schloming r...@alum.mit.edu
To: proton@qpid.apache.org
Sent: Monday, February 11, 2013 8:50:54 AM
Subject: Re: messenger accessors
Apologies for all the JIRA spam, as you can probably guess by now I've gone
through the unresolved JIRA list with Rob and updated the fix versions. As
it stands now there are about 26 JIRAs for the 0.4 release. I believe a
good number of these are partially or possibly entirely completed at this
Hello and welcome,
I had a little trouble tracking down the slide you're referring to. It
sounds like it could possibly be a bit dated given the title. Perhaps you
could describe your intended usage a little bit? In particular I'd be
interested in what you found lacking in the Messenger API, and
portion of the URL that
denotes this?
- Paul
On Mon, Feb 11, 2013 at 8:59 AM, Rafael Schloming r...@alum.mit.edu
wrote:
The example provided here[1] should be suitable for both peer to peer and
brokered operation, you just need to change the address you supply in
order
to switch
On Thu, Feb 14, 2013 at 5:44 PM, Alan Conway acon...@redhat.com wrote:
I'm looking (in python first) to encode messages that contain all the
different AMQP types. So far I was using the Data class to construct
different AMQP data fragments. However I'd like to move towards using a
map message
Can you post your code?
--Rafael
On Fri, Feb 15, 2013 at 5:22 AM, Michael Goulish mgoul...@redhat.comwrote:
Have I found a bug ?
scenario
{
receiver
{
I start a receiver and it subscribes to ports and 6667.
In a loop, it starts trying to recv messages. I set timeout
This is certainly somewhat more contained that what the qpid broker tree
has done. It's not quite two parallel build systems, but more two separate
build systems that happen to work on overlapping source trees. The cmake
build system covering the whole source tree (C, C++, Python, PHP, Ruby,
Perl,
Couldn't you use map message the way Rob described in his later email to
avoid having two?
--Rafael
On Fri, Feb 15, 2013 at 4:43 PM, Alan Conway acon...@redhat.com wrote:
Another wrinkle in my type testing saga:
Rob's DecoderImpl approach works in native java but not in JNI.
Conversely the
Source is here:
http://people.apache.org/~rhs/qpid-proton-0.4rc1/
Java binaries are here:
https://repository.apache.org/content/repositories/orgapacheqpid-239/
This is the first release after some significant build system changes, so
don't be surprised if there are a few kinks to work out.
It's actually already marked for 0.4. I believe ken is working on a fix. I
put out the RC1 anyways because I figured there would be fallout from the
build changes to work through anyways.
--Rafael
On Sun, Feb 17, 2013 at 6:05 PM, Michael Goulish mgoul...@redhat.comwrote:
Not immediately
There isn't currently a way to get any notification of connection loss
per/se. You might be able to accomplish what you want by checking the
status of the incoming message transfers. What is it you would do based on
the notification?
--Rafael
On Sun, Feb 17, 2013 at 6:43 PM, Bozo Dragojevic
Doh!
You had me scared there for a while.
--Rafael
On Tue, Feb 19, 2013 at 8:43 AM, Michael Goulish mgoul...@redhat.comwrote:
This just in.
It's a linking issue.
When I changed my two fn names from send() to my_send()
and from recv() to my_recv() ... no more problem.
This should be fixed now.
--Rafael
On Mon, Feb 18, 2013 at 12:31 PM, Ted Ross (JIRA) j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/PROTON-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580820#comment-13580820]
Ted Ross
Sounds reasonable to me.
--Rafael
On Wed, Feb 20, 2013 at 8:31 AM, Ken Giusti kgiu...@redhat.com wrote:
Fails to build on Centos-5 with a swig parse error (Syntax error on
input(1)).
Details:
swig-1.3.29-2.el5
chokes on the definition of pn_dtag() in include/proton/engine.h:75 -
It occurs to me there may be #defines you could key off when swig runs so
you could just remove the inline portion for swig.
--Rafael
On Wed, Feb 20, 2013 at 9:17 AM, Rafael Schloming r...@alum.mit.edu wrote:
Sounds reasonable to me.
--Rafael
On Wed, Feb 20, 2013 at 8:31 AM, Ken Giusti
Source posted here:
- http://people.apache.org/~rhs/qpid-proton-0.4rc2/
Java binaries here:
- https://repository.apache.org/content/repositories/orgapacheqpid-280/
I'd like to call an official vote soon, e.g. tomorrow, so please have a
look and share your results here.
Changes from RC1:
On Wed, Feb 20, 2013 at 2:43 PM, Phil Harvey p...@philharveyonline.comwrote:
Mostly looks good. One test is failing when run using the Java JNI binding
- see below.
Tested:
- Download tarball
- cmake, make, make install
- Observed .so and .jar files installed to correct locations
-
On Thu, Feb 21, 2013 at 10:53 AM, Rafael Schloming r...@alum.mit.edu wrote:
On Wed, Feb 20, 2013 at 2:43 PM, Phil Harvey p...@philharveyonline.comwrote:
Mostly looks good. One test is failing when run using the Java JNI
binding
- see below.
Tested:
- Download tarball
- cmake, make
1 - 100 of 432 matches
Mail list logo
