On Sat, Feb 8, 2014 at 12:15 PM, Fraser Adams <[email protected] > wrote:
> On 06/02/14 19:59, Rafael Schloming wrote: > >> On Tue, Feb 4, 2014 at 3:35 PM, Fraser Adams >> <[email protected]>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. --Rafael
