qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <...@alum.mit.edu>
Subject Re: A write up of some AMQP 1.0 Experiments
Date Sat, 08 Feb 2014 17:50:54 GMT
On Sat, Feb 8, 2014 at 12:15 PM, Fraser Adams <fraser.adams@blueyonder.co.uk
> wrote:

> On 06/02/14 19:59, Rafael Schloming wrote:
>> On Tue, Feb 4, 2014 at 3:35 PM, Fraser Adams
>> <fraser.adams@blueyonder.co.uk>wrote:
>>  It's probably worth aiming for consistency, but TBH I'm an awful lot more
>>> concerned that Proton Messenger doesn't seem to have a mechanism for
>>> setting link configuration and thus I couldn't use it for most of my more
>>> interesting examples, which was a shame.
>> I can confirm your observations are correct. As for intentions, I would
>> certainly like to support link configuration, the only reason it hasn't
>> happened yet is due to me being pulled in too many directions at once.
>> --Rafael
>>  Thanks Rafael, I can certainly sympathise with your position.
> Out of curiosity what sort of API did you have in mind for this? I guess
> something akin to the node/link JSON style config that is present in
> qpid::messaging style Address strings would seem most natural (and would
> give consistency with messaging and JMS) I guess too that would be fairly
> straightforward to pass through from pn_messenger_subscribe through
> pn_messenger_source to pn_messenger_link where I guess the real work would
> be done.
> I guess that you might have other ideas?

You pretty much got it. The only other option I was considering was a more
API-based access/configuration of things via the subscription object
returned by the subscribe call. Ultimately I think having both options
might not be bad.

There is already a working parser in the proton codebase, so it wouldn't be
hard to get something up and running. The parser in question is very
JSON-like, but it is aimed at being able to represent AMQP data in text
form with full fidelity. This makes it difficult to just go with a straight
JSON syntax since AMQP has a much richer set of datatypes than JSON
permits. At first my thought was come up with a convention to embed the
extended type information in a pure JSON structure, however after exploring
this avenue a bit I decided that it was in practice the same thing as
designing a new syntax that just happened to look really weird, so I gave
up trying to be strict to JSON syntax.

My intent with the parser was to use it consistently across the APIs
wherever it is convenient to be able to directly specify AMQP data with
text, so e.g. for constructing messages, saving/loading them to/from text,
logging them, and of course all the places where the protocol provides
extension points that can be specified as arbitrary AMQP data.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message