Tim Bray

And I've realized, at some point in the intervening years, that the whole thing could be done recursively without using the stepQueue at all. Which my intuition says would probably...

To be honest I doubt there's much difference. But worth checking.

The matching cost shouldn't differ in the slightest, but the flattening can obviously be affected… I think it'll probably be O(N) in something like the total number of field-steps.

Heh, not sure I agree on good 1st issue, you have to understand how ByteMachine fits together.

This is a great idea. The thing to watch out for is the performance of turning Avro messages into field name/value pairs, in the case of Jackson this is the...

Just need to be sure that this supports the nextToken() API, not just ObjectMapper. Also need to watch out for schemas, most of these binary formats can't be parsed without...

Just had a look at the Jackson Avro code. I was worried that it would implement nextToken() by deserializing into an object then traversing that, but it looks pretty efficient...

I agree with Rishi on syntax. I worry about implementation. If there are a bunch of these rules, the match-finding performance obviously becomes linear in their number. Right?

Here's what I believe: 1. When possible, we should check for duplicate keys in Rules as they are added, and reject such rules. 2. We should document that for Events,...

It may be a bit more complex than that. Ruler has multiple APIs with different approaches. In at least one place it uses Jackson `ObjectMapper`, which has the behavior you...