Open basman opened 11 months ago
Off the top of my head I think introducing ANTLR as a dependency seems a bit of an overkill to me, for the following reasons:
goProbe
(from a quick glance I'm not sure about the exact set of dependencies either, but let's say this: If executables / system libraries / CGO are / is required I'd consider that a red flag / blocker, because we went through a lot of trouble to get rid of any system dependencies and adding a new one would basically be a huge step backwards into v3 land).tcpdump
-style doesn't warrant the probably significant effort IMHO).tcpdump
(e.g. supports |
, ||
andor
to name just one). Can ANTLR cover all these cases (maybe a stupid question, but having never worked with it I'm just putting it out there)?That being said, I'm of course very opinionated on these things (mostly because of the point of minimizing dependencies, in particular seemingly complex ones like ANTLR) - If someone wants to take a shot at replacing the current lexer (while not introducing any red flags as hinted above), by all means.
@els0r What is your take? Anything to add?
I can totally follow the reasoning to use a grammar parser for the tcpdump-style syntax. Why reinvent the wheel? The support for it was discussed between basman and me previously. As it stands, most NOC engineers are still more familiar with the tcpdump syntax.
So why not support it?
After all, it’s just a subset of the rich query syntax we offer with goquery.
What I see as unreasonable overhead is to try to mold the current grammar into a format that ANTLR can use it. I’m also a burnt child regarding auto-generated code, so let’s proceed in an exploratory fashion and see if it’s worth it.
I don’t feel that strongly about introducing additional dependencies. But only if they don’t increase complexity in the build and later deployment of the software suite. Also, if they drag us back into C-Land, I’m less inclined.
Just to complete my initial idea, after playing around with ANTLR. We could generate the parser once and commit the generated go files to the repo. This way we only need ANTLR on the developer's machine when changing the grammar, avoiding another build dependency on build hosts.
Still the effort to replace the parser with ANTLR is significant and its not needed.
@basman Thanks a lot for putting in the effort and researching the potential impact - if it would only be required on a development machine (and even then only if the parser is touched) that would of course render most of my remarks irrelevant, so I'll leave it in your capable hands to decide whether it's worth the effort or not. If a different syntax makes more people / engineers use the tool then yay!
Looking at the complexity of the parser and the auto completion after we added the direction filter, using ANTLR as a lexer/parser could reduce code complexity.
Pro:
Con: