amqp — archive

[Alan Conway]

On Mon, 2015-02-16 at 10:28 -0800, Matthew Arrott wrote: > As I read this, there are two parts to this proposal: > > 1) Attribute Name Representation Optimization to obtain small size messages > > +1 with question: Is this attributeName list optimization something that > can be applied to all attributes across all subscriptions? I see it working like the QUERY operation response does. You can specify an arbitrary list of attribute names and an arbitrary filter that can return events of multiple eventTypes. For each matching event we simply match attribute names in the attributeList to the attributes of the event and fill in the value or NULL. This bothered me a bit when I first saw QUERY but now I find it gives a good simplicity/flexibility tradeoff. The bothersome part is it is not very "type safe". Say there are two event types X and Y, both have an attribute "foo" with completely different meanings. You subscribe with a filter that includes X and Y events with attributeList=["foo"]. When you get a compressed event from such a subscription you know it's a "foo" value but you don't know if it's an X.foo or a Y.foo so you don't know what it means. (Note this is exactly the same situation as issuing a QUERY with no entityType property and an attributeList that does not include the "type" attribute) The solution of course is "don't do that!" You can avoid ambiguity in two ways: 1. Have separate subscriptions each with only one event type OR 2. Include "eventType" in your attributeList. Then you know exactly what type each event is. What I now like about this is that it is easy to use on both ends. The QUERY messages or link attach properties are easy to construct and parse and the rules are easy to understand. It is possible to construct ambiguous queries but it's pretty obvious how to avoid it. I suspect a more type-safe approach would be much more verbose. > > 2) Generate a set of Standard EventTypes from the performatives in the > AMQP spec > > Question: Are the associated EventType attributes for each of the > performatives all well know and/or null? I don't know, I threw that out as a possible useful source of standard event types but I haven't tried to analyse them. It isn't my first priority implementation-wise but it will probably come fairly quickly. First I need events to satisfy a particular use case, but then I will need to fill out a generally useful set of event types. The AMQP spec might be the place to start. > >